Skip to main content

Messaging Patterns Workshop

Retrieval Prompts​

  1. State the rule for choosing point-to-point vs publish-subscribe.
  2. Define event notification and event-carried state transfer in one sentence each.
  3. State the dual-write bug in one sentence.
  4. Explain the outbox pattern's core claim in one sentence.
  5. Name two legitimate variants of the outbox relay.

Compare and Distinguish​

  • point-to-point queue vs pub-sub topic (consumer count, work vs broadcast)
  • SNS + SQS vs Kafka topic + consumer groups (how each realizes pub-sub)
  • event notification vs ECST (callback vs self-contained payload)
  • publish after commit vs outbox relay (race window, atomicity)
  • outbox polling vs CDC log tailing (simplicity vs latency)

Common Mistake Check​

For each, name the error and the correct alternative:

  1. "We use SQS standard to broadcast OrderPlaced to three services, and we get duplicates, not broadcast."
  2. "We have 20 subscribers on user-signed-up, all doing 'send welcome email' with small variations."
  3. "Our event carries the full user record, including the password hash."
  4. "We INSERT INTO orders then kafka.produce(...) in the same Python function, and sometimes events go missing after a crash."
  5. "We publish the event in the same thread as the HTTP response, so the customer sees the confirmation page faster."
  6. "We delete outbox rows immediately on successful publish to keep the table small."
  7. "Our outbox relay publishes, then updates published_at, and sometimes we see duplicate events -- bug?"

Scenario Drills -- Pick the Pattern​

For each scenario, pick and defend:

  • queue or topic?
  • notification or ECST?
  • outbox required?

Scenario A -- Image upload and thumbnail generation​

A user uploads an image. The system stores it in S3, then workers generate 4 thumbnail sizes. The product manager says it is fine if thumbnails are a second or two late.

Scenario B -- Order placement and downstream fan-out​

A user places an order. Billing must charge, inventory must reserve, notifications must email, analytics must record. Billing is the only flow whose failure cancels the order.

Scenario C -- Background batch: send a nightly report​

At 3 a.m., the system sends each customer a PDF of yesterday's transactions. 200k customers.

Scenario D -- Real-time fraud scoring as orders are placed​

Scoring must happen before the order is fulfilled. The fraud service must return a decision within 200 ms to the checkout service.

Scenario E -- Customer profile update propagated to 6 systems​

The user changes their email. The profile service updates; 6 downstream systems (marketing, support CRM, billing, analytics, access control, feature flags) all want the latest email.

Expected shape of answers:

  • A: queue (work distribution); thumbnails; no outbox needed (workers are idempotent by URL).
  • B: topic (broadcast) for OrderPlaced; ECST for the payload (so consumers do not hammer checkout); outbox required on checkout.
  • C: task queue; ECST of the report summary; outbox not needed if emission is a scheduled job with idempotent send.
  • D: synchronous request/reply (command with reply), not an event. This is not an EDA problem.
  • E: topic; choose between ECST (ship the new email) and notification (consumers fetch). ECST often better here because the downstream systems want to keep running while the profile service is down.

Outbox Pattern Sketch​

Design the outbox for a BookingService that creates a booking and emits BookingCreated. In 30 minutes:

1. DDL​

Write the CREATE TABLE statements for:

  • bookings (primary entity)
  • outbox (event buffer)

Include indexes that the relay will use.

2. The write transaction​

Write the pseudocode (or real SQL) for the create_booking transaction that atomically inserts the booking and the outbox row.

3. The relay​

Write the pseudocode for a polling relay:

  • selects unpublished rows FOR UPDATE SKIP LOCKED
  • publishes to the broker
  • updates published_at
  • handles publish failure

4. Consumer idempotency​

Describe how a BillingService consuming BookingCreated dedupes by event_id. Pick the dedup store and TTL.

5. Operational questions​

  • What metrics do you emit about the outbox?
  • What alert threshold triggers pager?
  • How do you archive the outbox table?

Notification vs ECST Rewrite​

Take this thin event:

{ "event_type": "OrderPlaced", "order_id": "ord_9f2a", "occurred_at": "..." }

And:

  1. Identify three plausible consumers.
  2. For each, decide whether it prefers notification or ECST.
  3. If ≥2 want ECST, write the ECST payload.
  4. Decide which fields are sensitive (PII, secrets) and keep them off the event.

Evidence Check​

This page is complete only when:

  • You answered the 5 scenario drills with pattern + reason.
  • You produced a runnable-looking outbox sketch (DDL, write txn, relay, consumer dedup).
  • You rewrote the thin OrderPlaced event as both notification and ECST, and you can explain when to pick which.
  • You can state the dual-write bug and the outbox fix in your own words, without looking.