CAP Theorem and ACID : What Happens When Your Servers Stop Talking to Each Other

Early in my career I built a small inventory feature that worked perfectly on my laptop. In production, with two servers and two databases, we sold the same last item to two different customers. Nothing was “broken”. Both servers were healthy, the code had no bug, and the network between them had a short hiccup. That was my first real lesson in distributed systems, and it is exactly what the CAP theorem describes.

This article walks through CAP and ACID in plain language with practical examples. These two ideas get mixed up a lot, and understanding both makes system design discussions and interviews much easier.

Why we run more than one server

Take a simple shopping app:

              Shopping App
                   |
          ---------------------
          |                   |
      Server A            Server B
      (Mumbai)            (Delhi)
          |                   |
       Database            Database

We do this for good reasons. If Mumbai goes down, Delhi keeps serving customers. Users also get faster responses from a nearby server.

But there is a catch. The two databases need to stay in sync, and they sync over a network. Networks fail. Cables get cut, routers misbehave, cloud regions lose connectivity. When Mumbai and Delhi are both running but cannot talk to each other, we have a network partition: