Skip to main content

External Exercises

Design drills, implementation katas, and reference system-design interviews to build fluency beyond the module's internal practice pages.

How To Use This Page​

  1. Finish the relevant concept page first.
  2. Attempt the drill from memory before consulting the source's answer.
  3. Keep a mistake log with tags such as command-disguised-as-event, published-before-commit, missing-dedup, hot-partition, choreography-too-complex, CQRS-overkill.
  4. Prefer designing in ASCII or mermaid so you can review your old sketches.

Lane 1: Event Modeling (Cluster 1)​

Use this lane when your main gap is what an event is and how to name one.

Design exercises (paper or whiteboard)​

  • Pick three CRUD APIs you know (e.g., GitHub's repo API, Slack's message API, Stripe's charge API). For each, list 10 endpoints and rewrite each as either a command, an event, or a query.
  • Pick one domain you know well. Do a solo "event storming": 20 events in 20 minutes, sticky-note style, then trim and rename.
  • Take any "event payload" from a real system (webhook from Stripe, GitHub, Slack) and apply Concept 01's checklist. Does it pass?

Optional reading-paired drills​

Target outcomes:

  • 30 events named correctly in past tense across 3 domains
  • 5 cases of a "command disguised as event" identified and corrected
  • 1 event storming session completed end-to-end

Lane 2: Messaging Mechanics and Outbox (Cluster 2)​

Hands-on implementation katas​

Use a local Docker setup (Kafka + Postgres) or a hosted sandbox.

  • Kafka 101 from Confluent Developer: Apache Kafka 101 -- work through the producer, consumer, and topic exercises.
  • Outbox in Postgres + Kafka: implement the outbox pattern end-to-end; write 50 orders through the service, crash the relay mid-batch, restart, verify no event is lost or duplicated (consumer-side dedup).
  • Debezium hands-on: follow the Debezium tutorial to point CDC at a Postgres outbox table.

Design drills​

  • Design a queue + DLQ topology for an image-processing service under a load spike. Specify visibility timeout, max receive count, DLQ disposition.
  • Design a topic partitioning strategy for a payments system handling 50k TPS with 3 downstream consumer groups.

Target outcomes:

  • 1 working outbox implementation on your machine
  • 5 broker design drills with justified partitioning and retention
  • 1 DLQ triage runbook written for a fictional on-call engineer

Lane 3: Workflow, Sagas, and Idempotency (Cluster 4)​

Orchestration platforms​

  • Temporal tutorial: learn.temporal.io -- implement the "money transfer" workflow tutorial end to end. It is the best single saga exercise.
  • AWS Step Functions: Getting started -- implement the same money transfer as a state machine.

Saga design drills​

  • Design a saga for: a travel booking (flight + hotel + car), a loan approval with credit check + underwriting + funding, or a software onboarding with trial-to-paid conversion.
  • For each: list steps, compensations, terminal states, non-compensatable steps, correlation IDs, observability.

Idempotency drills​

  • Take a real integration you have built that calls an external API. Redesign the retry path with an idempotency key and describe the behavior under every combination of (first call succeeds/fails) × (retry reaches service/fails).

Target outcomes:

  • 1 complete Temporal or Step Functions implementation
  • 3 saga designs with full compensation stories
  • 2 redesigned non-idempotent consumers with dedup + idempotency keys

Lane 4: Event Sourcing, Projections, CQRS (Cluster 5)​

Implementation-oriented​

  • Marten on Postgres (C# / .NET) or EventStoreDB or Axon (Java): implement a small event-sourced aggregate (a shopping cart, a support ticket). Fold events to compute state; persist; replay.
  • Build a projection: over the same event stream, build two read models -- one denormalized table, one search index. Reset the consumer offset to zero and rebuild both.

Reading-paired drills​

Target outcomes:

  • 1 event-sourced aggregate with snapshot support
  • 2 projections from the same stream, one rebuilt from offset zero
  • 4 CQRS decisions written up with defenses

Lane 5: System Design Interview Drills​

Apply this module under interview pressure.

Classic prompts​

  • "Design a ticketing system" (Ticketmaster, Resy) -- expect to discuss: orders, inventory, reservations, sagas, idempotency, CQRS for the browse side.
  • "Design a chat system" (WhatsApp, Slack) -- messages as events, delivery semantics, fan-out, read models for conversations.
  • "Design a ride-dispatch system" (Uber) -- driver state, trip state, events across surge pricing and dispatch, long-running saga for a trip.
  • "Design a payments platform" (Stripe) -- idempotency is table stakes, event sourcing for the ledger, outbox pattern for webhooks.
  • "Design a real-time analytics pipeline" -- Kafka, stream processing, projections for dashboards.

Where to find more​

Target outcomes:

  • 3 full system design sketches with event-driven components justified
  • 1 whiteboard-timed (60 min) end-to-end design
  • 1 mistake log entry per interview attempt with the specific thing you forgot

Self-Curated Problem Set​

Build a custom set with these minimums:

  • 5 events modeled cleanly (past tense, minimum metadata, two plausible consumers each)
  • 3 messaging-pattern decisions (queue vs topic, notification vs ECST) with written justification
  • 1 full outbox implementation or detailed sketch
  • 1 Kafka topic design with partitioning, keying, retention, and replication decisions
  • 2 full sagas (1 choreographed, 1 orchestrated) including compensations
  • 2 non-idempotent consumers redesigned
  • 3 CQRS yes/no/partial decisions with defense

Completion Checklist​

  • Completed at least one lane in full
  • Logged at least 10 real mistakes with tags
  • Wrote at least 5 full sentence-form event/command/query justifications
  • Implemented at least one outbox or Temporal workflow locally
  • Drew at least one saga on a whiteboard under a 20-minute timer
  • Defended at least 3 CQRS decisions for real or realistic scenarios