# If CAP were real-time: adding timing requirements to the definition of availability

DevFeed: [If CAP were real-time: adding timing requirements to the definition of availability](<https://devfeed.tech/articles/if-cap-were-real-time-adding-timing-requirements-to-the-definition-of-availability-21693.md>)

Original publisher: [Read original article](<http://blog.thislongrun.com/2015/06/real-time-CAP-theorem.html>)

Author: Nicolas Liochon (noreply@blogger.com)

Published: 2015-06-14T18:20:00Z

Content type: article

Language: en

Sources: [Nicolas Liochon](<https://devfeed.tech/sources/nicolas-liochon.md>)

Topics: [Availability](<https://devfeed.tech/topics/availability.md>), [Networks](<https://devfeed.tech/topics/networks.md>), [Protocol (disambiguation)](<https://devfeed.tech/topics/protocol.md>), [Algorithms, Complexity](<https://devfeed.tech/topics/algorithms-complexity.md>)

Tags: [acid](<https://devfeed.tech/tags/acid.md>), [asynchronous](<https://devfeed.tech/tags/asynchronous.md>), [availability](<https://devfeed.tech/tags/availability.md>), [cap-theorem](<https://devfeed.tech/tags/cap-theorem.md>), [consistency](<https://devfeed.tech/tags/consistency.md>), [database](<https://devfeed.tech/tags/database.md>), [distributed-system](<https://devfeed.tech/tags/distributed-system.md>), [durability](<https://devfeed.tech/tags/durability.md>), [latency](<https://devfeed.tech/tags/latency.md>), [network](<https://devfeed.tech/tags/network.md>), [partition](<https://devfeed.tech/tags/partition.md>), [protocol](<https://devfeed.tech/tags/protocol.md>), [real-time](<https://devfeed.tech/tags/real-time.md>), [tcp](<https://devfeed.tech/tags/tcp.md>)

## AI overview

This article explains why delays are often misunderstood when applying the CAP theorem. It distinguishes the asynchronous network model used in the CAP proof from TCP and argues that adding timing requirements to CAP can make the model applicable to delays as well as partitions.

## Source excerpt

"If you are not too long, I will wait here for you all my socketReadTimeout." - Oscar Wilde, quoted from memory. This post is part of the CAP theorem series. You may want to start by my post on ACID vs. CAP if you have a database background but have never really been exposed to the CAP theorem. The post discussing some traps in the 'Availability' and 'Consistency' definition of CAP could also be used as an introduction if you know CAP but haven't looked at its formal definition. Delays are a hot source of confusion when using CAP. Confusion arises out of the understanding of what an asynchronous network--the network model used in the CAP proof--actually is. Confusion arises out of what TCP is exactly. Confusion arises out of the definition of availability in CAP--which does not have any timing requirement. In this post, I'm not only going to cover why speaking about delays when the network is asynchronous is a mistake or why TCP is more than an asynchronous network: I will also show that adding timing requirements to CAP makes it usable not only for partitions but also for delays. Why are there never any delays in academic networks? The CAP proof by Gilbert and Lynch uses an "asynchronous model, in which system components take steps at arbitrary speeds." The key point is that there can be no delay, because there is absolutely no timing guarantee, so a message is never late. That's by design, as stated by Lynch: "algorithms designed for the asynchronous model are general and portable, in that they are guaranteed to run correctly in networks with arbitrary timing behavior." On such a network model, you cannot build an application that needs a guaranteed response time. You cannot even provide an approximation of its expected response time. You can at best prove that the application will answer... someday. You can calculate the number of messages required by a given protocol, but you cannot, in any case, calculate a response time. Such a network is never sufficient to wri