ACID vs. BASE: Transaction Models Simplified

Issue #23 of "System Design Interview Roadmap" - Part II: Data Storage

I was on a call with a team whose e-commerce platform had just experienced a partial outage during their biggest sale of the year. The culprit? An unexpected interaction between their payment and inventory systems when data

base connections were overwhelmed. "We thought we understood transactions," the lead developer told me, "but when the system was stressed, money disappeared, and customers were charged for out-of-stock items."

This scenario plays out more often than you'd think, and it often stems from a fundamental misunderstanding of transaction models. Today, we'll demystify the eternal database debate: ACID vs. BASE.

The Transaction Dilemma

Imagine you're designing a money transfer system. Alice wants to send $100 to Bob. This seemingly simple operation requires two critical steps:

1. Deduct $100 from Alice's account

2. Add $100 to Bob's account

What happens if your system crashes between steps 1 and 2? Alice loses money, Bob never receives it, and you have an accounting nightmare. This is why we need transaction models to ensure data integrity.