Designing for eventual consistency
On This Lesson 4 topics
This lesson is planned. The outline below lists the topics it will cover. The full lesson has not been published yet.
In this lesson
make lag a designed behavior, not a surprise.
Planned topics
- Show honest intermediate states: "order pending", "payment processing".
- Return
202 Acceptedwith a status URL for work that finishes later. - Read-your-writes tricks: read from the primary after a write, return the created resource in the response, or pass a version the reader waits for.
- Make updates idempotent and commutative where possible so order does not matter.
- Expect conflicts to be rare but define a rule (last write wins, merge, or ask the user).
Draft outline details
Demonstration
POST /orders -> 202 Accepted, Location: /orders/42
GET /orders/42 -> {"status":"PENDING"} ...later... {"status":"CONFIRMED"}Check your understanding
Why return PENDING rather than waiting inside the POST?
Show answer
Downstream steps are asynchronous; waiting hides lag and ties up resources.
Practice
Apply this lesson with the module's lab, exercises and quiz.
Marking a lesson complete is optional and you can undo it any time. Your progress stays in this browser.