Consistency, Availability & Latency Requirements

In this chapter

We'll meet transaction requirements, consistency requirements, availability requirements, and latency requirements — the real promises a database choice has to honor, applied to GreenMart's own next expansion.

8–10 min

The Problem in Real Life

The shape of the data is clear. Mike's next question is sharper: if two warehouses in two countries both try to dispatch the same order at once, what's GreenMart actually promising happens?

That's not a data-shape question anymore. It's a promise question — and this course has spent an entire Act, the twelfth, on exactly how expensive that promise can get.

If two warehouses both grab the same order, what are we actually promising won't happen?

Mike

What GreenMart Is Actually Promising

Transactions and consistency are real promises

Whether multi-step operations succeed or fail together, and how strict correctness needs to be, are decisions with real, honest costs.

Availability and latency need real numbers

Acceptable downtime and acceptable response time aren't feelings — they're specific targets a database choice has to meet.

Four real, separate promises hide inside Mike's one question, and Act 12 already taught the honest cost of each.

On correctness across multiple steps. Transaction requirements ask whether an operation genuinely needs multiple writes to succeed or fail together — Act 4's own conditional writes and Act 12's own distributed transactions and 2PC both live here. Dispatching an order and decrementing fleet capacity together, correctly, is exactly this kind of requirement.
On what "correct" means across machines. Consistency requirements ask how strict GreenMart needs to be about every reader seeing the same, most-current answer — Act 12's CAP theorem and PACELC named this trade-off precisely: strict consistency costs availability or latency during a real partition, and GreenMart has to decide, honestly, which side of that trade it's willing to be on for this specific data.
On staying up. Availability requirements ask how much downtime is actually acceptable — a flash-sale stock counter (Act 3) tolerates very little; an end-of-day analytics report tolerates far more. Two dispatching warehouses genuinely need to stay available during a network hiccup, not freeze entirely.
On how fast is fast enough. Latency requirements ask for a real number, not a feeling — a fleet-dispatch decision needs an answer in well under a second to be useful at all, the same real standard Act 3's Redis and Act 9's vector search were both built around.

For GreenMart's fleet-and-order requirement, the honest answer is now on the table: real transaction requirements around dispatch-and-decrement, strong consistency preferred but genuine tolerance for a brief, honest reconciliation window during a rare partition, high availability, and low latency worldwide. None of these are free — each is a real trade-off, not a wish list, and every one of them was already taught, concretely, somewhere earlier in this course.

Key Takeaway

Consistency, availability, and latency aren't abstract database features — they're promises GreenMart makes to its own customers, and every one of them costs something real, which is exactly why naming them honestly, before picking a database, matters.

Why This Matters

A database chosen without naming these requirements first tends to surprise GreenMart exactly when it's most expensive to be surprised — during a real partition, a real spike, or a real multi-step failure. This chapter is what makes that promise deliberate instead of accidental.

GreenMart now has a second real category of facts about the fleet-and-order requirement — its transaction, consistency, availability, and latency needs. The next chapter adds a third: how big, how fast-growing, and how geographically spread this workload actually is.