Notify’s big night

The brief

Notify takes on a second customer: a photo-challenge app, on new provider accounts with starter plans that Notify can’t change — push takes up to 100 sends a second (about 40 ms each), email up to 75 (about 200 ms). A quick first version wired it the old way: the Notify API calls the push provider while the app waits, and email isn’t connected yet. The app sends one post per notification, 60 a second on a normal evening, and every post must reach both push and email. At second 30 tonight’s challenge closes: 150 posts a second for 20 seconds, then back to 60. Build Notify’s pipeline for the app with queues, a topic and senders. A sender takes messages from a queue at the pace you set and sends each to a provider; on the canvas’s default small server it carries about 25 a second at 80% busy. Any server kept above 95% busy for 5 seconds goes down and stays down. The score counts what each provider actually sends by the end of the run, so every post has to get through to both. So work it out: how long after second 50 are the last pushes and the last emails sent?

What it checks

1. 1Predict the response time when slow work moves off the request path onto a queue.
2. 2Explain how a queue lets a service with a fixed capacity, such as a provider with a send cap, work at its own steady rate — sized for the average, not the peak — and why a consumer that is down then only delays the work.
3. 3Predict a queue's throughput and backlog as workers are added, up to the point where a shared downstream — a provider's cap, a database — becomes the bottleneck.
4. 4Choose a topic or a queue from whether a message is a job for one worker or news for anyone interested — and combine them, with a queue per subscriber and competing workers on it.

Brush up first

• Async work with a queue
• Load leveling
• Competing consumers
• Pub/sub fan-out

More practice

1. Keep it aliveOpen8 min
2. Launch dayFree with an account20 min