Choosing Your Consistency Model Before It Chooses You
Every database makes a consistency trade-off on your behalf. Most teams find out which one during an incident.
Every distributed database ships with a consistency model baked into its defaults, and most teams never explicitly decide whether that default matches what their application actually needs.
Where the mismatch shows up
Eventual consistency is usually fine for a social feed and genuinely wrong for a checkout flow. The database does not know the difference — it applies the same guarantee everywhere unless a team deliberately overrides it per operation.
- Identify the handful of operations in your system where a stale read is actually unacceptable.
- Apply strong consistency selectively to those paths rather than globally — the cost is real and should be spent deliberately.
- Document the consistency guarantee per data path so the next engineer does not have to reverse-engineer it during an incident.
The practical exercise
List your five most critical write paths and write down, explicitly, what happens if two of them race. If nobody on the team can answer that today, that is the actual next task — before the next database migration, not after.