There are multiple aspects and quality that are desirable for a distributed system. Among these are consistency and availability. According to the CAP theorem, if partition tolerance is a must, the system designer can choose from a spectrum of models that trade off between consistency and availability. Jepsen provides an interactive diagram that shows multiple models that trade off between very consistent and very available (although not an exhaustive list). For systems that require high availability, the designers may choose to use a weaker consistency model.

In this question, let's take strong consistency to mean linearizability and weak consistency to mean any other models weaker than linearizability (e.g. sequential consistency, causal consistency, strong eventual consistency (SEC), etc.). One of the consequential requirements of linearizability is that the system needs to have a global clock.

In many modern systems, all operations performed are associated with a timestamp at which the operation was executed. This implies that some global clock is used. Therefore, does it makes any sense to design a system to be weakly consistent?

  • 1
    How accurate do you thing those timestamps are? If you go for any amount of redundance, you'll have more than one OS/machine clock that these timestamps are taken from. Thus, the data you store is only as linearizable as your timestamps are accurate. Sure, NTP is the go-to solution to this problem. But you then somewhat shift the problem to your NTP servers/authorities; these need to be reliable and accurate, too.
    – marstato
    Commented Mar 18, 2020 at 8:27
  • I agree that timestamps have the possibility to be inaccurate and unreliable. However, they are still used in many systems. Take StackExchange for example; the timeline function below the vote will show a sequence of operations performed on this question, along with a timestamp. If such systems choose to associate timestamps along with operations already, does it makes any sense to model the system as weakly consistent?
    – krismath
    Commented Mar 18, 2020 at 8:40
  • Sure it does. For example in case any possible problems can be rectified eventually. Say e.g. a booking system: you could e.g. check booking capacity before every booking. Or you could have the capacity weakly consistent, giving you a speed-bonus and the risk of over-booking. But over-booking isn't necessarily bad: if you noticed that you actually overbooked, you can cancel bookings. Or maybe wait with cancelling them in case another customer cancels their booking, making enough room for the previously over-booked customers. edit: i'll post this as an answer.
    – marstato
    Commented Mar 18, 2020 at 13:19

1 Answer 1


Yes, it does. It makes sense whenever rectifying the consistency problems after-the-fact has advantages over preventing them in the first place. The reduced performance needed to ensure strong consistency is always a factor.

For example take a hotel booking system. You can separate accepting the booking and confirming it. You allow people to place bookings; the booking system has an eventually consistent information on the capacity and will, by logical consequence, allow overbooking. Once your eventually consistent capacity is at 0 you can be sure that you are either fully booked or overbooked. You can then choose the customers whose bookings you'll cancel or not confirm (legal differences mostly).

With this system you could probably reach a better utilization of the hotel than if you had a slow website that blocks new bookings once the capacity is reached (mostly due to UX problems with performance and people tending to cancel bookings).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.