Typorithm · hard

Event-Driven & Idempotency

event-driven-designsystem-designevent-drivensagaidempotency

Saved on this device

Full lesson · 8 learning steps Open any exercise for focused practice

Step 1 of 8 · intro card

Learn Event-Driven & Idempotency

Communication

Event-driven systems emit events that other services react to, decoupling them. A saga coordinates a distributed transaction with compensating actions, the outbox pattern publishes reliably from a DB transaction, and idempotency keys dedupe retries while you accept an eventual-consistency window.

In an event-driven system a service records that something happened and emits an event; other services subscribe and react. The producer does not know or wait for its consumers, which keeps the system loosely coupled and easy to extend.

There is no single ACID transaction across services. A saga models a distributed transaction as a chain of local steps, and if a later step fails it runs compensating actions to undo the earlier ones. The outbox pattern solves the dual-write problem: the event is written in the same DB transaction as the state change, then a relay publishes it reliably.

Because consumers may retry, each carries an idempotency key so a duplicate can be deduped instead of applied twice. The price of all this asynchrony is an eventual-consistency window: for a short time services can disagree before they converge.

Event-driven: emit events, other services react — decoupled.

Saga: distributed transaction with compensating actions.

Outbox + idempotency keys make publishing and retries reliable.

events:
  pattern: emit-and-react
  saga: distributed-transaction
  outbox: reliable-publish
  idempotency: dedupe-by-key
  eventual: consistency-window

Read the implementation

Connect each part of the code to the concept before you type.

1. Event-driven

Services emit events about what happened and other services react to them, keeping the producer and consumers decoupled.

pattern: emit-and-react

2. Saga

A saga coordinates a transaction across services as a sequence of local steps, each with a compensating action to undo it on failure.

saga: distributed-transaction

3. Outbox

The outbox pattern writes the event into the same database transaction as the state change, then publishes it reliably.

outbox: reliable-publish

4. Idempotency

An idempotency key lets a consumer recognize and drop a duplicate retry instead of processing it twice.

idempotency: dedupe-by-key

5. Eventual consistency

Reacting to events asynchronously means there is a window where services disagree before they converge — eventual consistency.

eventual: consistency-window

A complete learning loop

Understand

Read the concept map and follow the code breakdown.

Reconstruct

Type the implementation, repair mistakes and work through every recall exercise.

Verify

Use the final check without hints; revisit weak concepts in short practice sessions.