I've interviewed dozens of engineers at the senior level. When I ask them to explain eventual consistency, most recite the textbook answer: "data will converge to a consistent state — eventually." What they can't tell me is what that looks like when something goes wrong at 2 AM with real money on the line.
After 11 years building distributed systems — several in the Brazilian fintech space on top of PIX — I've come to believe that eventual consistency is the most confidently misunderstood concept in backend engineering.
What the Textbook Gets Right (and What It Skips)
The CAP theorem tells you a distributed system can guarantee at most two of three properties: Consistency, Availability, and Partition tolerance. Under network partitions — not exceptional events, they're normal — you choose between C and A.
Eventual consistency is the CP-to-AP trade. You relax the guarantee that every read reflects the most recent write, in exchange for continued availability. The system promises that, absent further writes, all replicas will converge.
