CAP theorem: under a network partition, you must choose between Consistency (every read sees the
latest write) and Availability (every request gets a response) — you can't have both. Most
microservice/event-driven systems deliberately lean Available + eventually Consistent (AP), which is
exactly the eventual-consistency tradeoff from the Event-Driven topic, now named formally.
The distributed transaction problem: you can't wrap a change across two separate services'
databases in one ACID transaction the way you could across two tables in one database. The
Saga pattern is the standard answer: a sequence of local transactions, each in its own
service/database, where each step publishes an event/command triggering the next — and if a later
step fails, previously completed steps are undone via explicit compensating transactions (e.g.
"CancelReservation" to undo "ReserveInventory") rather than a real rollback.
State the CAP theorem's core tradeoff.
tap to reveal answer
Under a network partition, a distributed system must choose between Consistency (every read reflects the latest write) and Availability (every request gets a response) — it cannot guarantee both simultaneously during the partition.
Why can't you use a normal ACID transaction across two microservices' separate databases?
tap to reveal answer
ACID transactions are scoped to a single database/resource manager; two services owning separate databases have no shared transaction coordinator spanning both without a distributed transaction protocol (2PC), which most modern architectures avoid due to the coupling and availability cost.
What is a compensating transaction in the Saga pattern, with an example?
tap to reveal answer
An explicit action that semantically undoes a previously completed step when a later step in the saga fails — e.g. if 'ReserveInventory' succeeded but a later payment step fails, a 'CancelReservation' compensating action releases the reserved stock, since there's no real database rollback spanning both services.