A payment rarely lives in one place. Charging a card, updating a ledger, reserving stock and sending a receipt can each happen in a different service with its own database, and any of them can time out or crash halfway through. Distributed systems engineering is the work of keeping money and data correct when that happens.
You'll start with distributed transactions: why two-phase commit struggles across microservices, and how the saga pattern replaces it with a chain of local transactions and compensating actions. Then you'll learn idempotency keys, the technique that lets a client retry a payment safely without being charged twice. After that you'll meet Apache Kafka and event-driven messaging, and finish with the transactional outbox pattern, which makes sure a database change and the event announcing it never fall out of sync.
Remember that most message brokers guarantee at-least-once delivery, which means the same message can arrive more than once. That is why idempotency shows up in almost every lesson here: consumers, retries and compensating steps all have to be safe to run twice. Once you've finished this module, move on to Lending & Trading Systems.
Why two-phase commit is a dead end for microservices, how a saga chains local transactions with compensating actions, how choreography and orchestration coordinate the same saga, and the isolation problems that sagas introduce at scale.
How a retried request can charge a customer twice, and how an idempotency key sent with the request lets the server process the payment only once. Also covers retrying safely with exponential backoff and jitter.
A beginner introduction to Apache Kafka, the data integration and real-time processing problems it was built to solve, and how it decouples the systems that produce data from the systems that consume it.
What goes wrong when a service saves to its database but crashes before publishing the event, and how writing the event to an outbox table in the same transaction keeps your data and your messages consistent.