Capstone 10 · Backend

The Switchboard

Services send webhooks. Receiving them reliably is harder than it looks, and most applications get it wrong quietly. Build the thing that gets it right. It accepts incoming events, verifies their signature so it cannot be fed forgeries, stores them, and delivers each one to every registered subscriber. Delivery fails constantly in reality: a subscriber is down, slow, or returns a 500. So it retries with exponential backoff and jitter, gives up after a bounded number of attempts, and puts the failures somewhere a person can see and replay them. The requirements that make it real: accept an event once even if the sender delivers it three times, which means deduplicating on the sender's event id. Never lose an accepted event. Respond to the sender fast, which means accepting and queueing rather than delivering inline. Keep a delivery log per subscriber so somebody can answer 'did that arrive'. This is unglamorous and it is exactly the kind of thing a backend interview goes deep on.

Concepts used

Queues and workersRetries and backoffIdempotencySignature verificationObservabilityAPI designFailure testing

Your dataset

A generator that produces events at a configurable rate, plus a subscriber you can make fail on demand.

Milestones

1Accept an event, verify its HMAC signature, and reject a forged one.
2Deduplicate on the sender's event id, so a repeated delivery is stored once.
3Accept and queue, responding to the sender in milliseconds rather than after delivery.
4Deliver to subscribers in a worker, with a per-subscriber delivery log.
5Add retries with exponential backoff and jitter, and a maximum attempt count.
6Add a dead letter store for exhausted deliveries, with a replay endpoint.
7Prove it under failure: make a subscriber fail for two minutes and show every event arrives afterwards.
8Expose metrics that answer the real questions: queue depth, delivery latency, failure rate per subscriber.

The graded core

The rest of this project is yours to shape. This one function is the piece everything else depends on, so it runs against hidden tests to prove it is right before you build outward.

◈ Graded Challenge

The delivery decision, isolated. Write next_delay(attempt, status, max_attempts) returning the number of seconds to wait before the next attempt, doubling from 1 (so attempt 1 waits 1, attempt 2 waits 2, attempt 3 waits 4). Return 0 when the delivery succeeded, meaning a status below 400. Return -1 when it must not be retried at all, meaning a 4xx that is not 429. Return -1 as well when attempt has reached max_attempts, since the next stop is the dead letter store.

Name it exactly: next_delay(attempt, status, max_attempts)

4 visible + 5 hidden
loading editor…

Your workspace

Build the full project here. Work through the milestones in order, in both languages.

SANKOFA SANDBOX
loading editor…
Your turn → Build it in Python first, then rebuild it in JavaScript. The logic transfers, only the syntax changes.
← All projectsNext: The Open Archive API →