Section 2: Two Clocks, One Contract - Requirements (Functional & Non-Functional)
Executive Summary: This section turns Section 1's assumptions into a contract. Seven functional requirements split cleanly into a control plane (topics, subscriptions, policies) and a data plane (publish, deliver, retry, report). The non-functional requirements put numbers on latency, fan-out, availability, durability, delivery semantics and propagation. Two ideas carry the section. The publisher's clock and the subscriber's clock must be decoupled. And there is one requirement most candidates never write down: a failing endpoint or tenant must not slow anyone else.
The clarifications are done. The interviewer leans back: "Fine. What exactly are you committing to?" "Notifications should be fast and reliable" is an adjective. "An acked message survives the loss of any one AZ" is a promise. So you write requirements in that form.
The Functional Contract: Seven Verbs in Two Planes
| # | Requirement | Plane |
|---|---|---|
| FR1 | Create, get, list and delete topics | Control |
| FR2 | Subscribe and unsubscribe an endpoint, with a confirmation handshake before anything is delivered | Control |
| FR3 | Attach a filter policy, a retry policy and a DLQ to each subscription | Control |
| FR4 | Publish a message to a topic, singly or in a batch of up to 10 (256 KB max) | Data |
| FR5 | Deliver a copy to every matching subscriber over 5 protocols: queue, HTTP/S, mobile push, email, SMS | Data |
| FR6 | Retry failed deliveries per the subscription's policy, then hand them to its DLQ | Data |
| FR7 | Expose per-subscription delivery metrics: delivered, failed, retried, sent to DLQ | Data |
You draw the line between the planes on purpose, because they have opposite needs. The control plane runs at a low rate and must be correct. The data plane runs at hundreds of thousands of operations a second and must be fast.
Interviewer: "FR7 is metrics. Can ShopFast ask whether order #84721 was delivered to the fraud webhook?"
You: "Not through the publish response. Publish answers one question: is the message durably accepted? Delivery happens later, three times for #84721 (warehouse queue, fraud, partner), possibly hours apart if the partner is down. ShopFast sees delivery health as per-subscription metrics, and anything that exhausts its retries lands in their DLQ. Per-message delivery logs are a fair follow-up for Section 12."
Sign in to continue reading
The rest of this lesson is available with a free account. Signing in with Google or Microsoft is free.
Sign in to read the full lesson