Study route · Scalable notifications

Interview prep

A focused route through the reading and exercises for a notification-system design interview, with networking follow-ups for the App Connector discussion.

Main reading, in priority order

The interview update mentions delivering notifications to users, including configuration changes and events. Begin with the delivery contract and the recipient before choosing a transport.

1. Notifications, SSE, and real-time updates

   Study transport choice, reconnects, replay, slow subscribers, and delivery across multiple server instances.

   Explain: Do recipients need the latest state or every event? When would you choose polling, SSE, WebSockets, or webhooks?

2. Background jobs and task queues

   Study durable work, bounded worker concurrency, asynchronous response contracts, backlog monitoring, and recovery.

   Explain: What survives a restart? What does an accepted response promise? What if the worker finishes the effect but crashes before acknowledging it?

3. Webhooks and event-driven design

   Study signatures over the raw body, ambiguous timeouts, duplicate delivery, retries, payload versions, and subscriptions.

   Explain: What if processing succeeded but the response was lost? Which operations must be atomic for a retry to be safe?

4. Bounded worker pools and context cancellation

   Study concurrency limits, overload, deadlines, goroutine ownership, and shutdown.

   Explain: Where does excess work wait? Who stops it? How do you prove a worker has exited after cancellation?

5. Dynamic configuration

   Study periodic refresh and local snapshots, then reason about push updates, versions, ordering, and resynchronization.

   Explain: Should a notification carry the new state or tell a client to fetch it? How stale may configuration become?

6. Distributed rate limiting

   Study limits shared across replicas, per-customer budgets, and downstream protection.

   Explain: How do you keep one tenant or slow endpoint from consuming everyone's workers? Which limits apply to requests, queued work, and active sends?

Networking follow-ups

Use these to strengthen the address-mapping and stale-state discussion. Keep the main study effort on notification design.

Exercises to turn into failure experiments

The source links open the actual exercise files in the browser. The changes and experiments below are suggested extensions; they are not already implemented. The standalone exercises cover Part 2. The SSE and webhook examples are in the chapters above.

1. HTTP cancellation and an uncertain result

   Open server sourceOpen client sourceRead the HTTP chapter

   Point the client at http://127.0.0.1:8083/. Give it a timeout shorter than the server's five-second wait. Log cancellation on the server; its existing cancellation branch tries to write to a client that may already be gone.

   Next, model an effect that finishes before the reply reaches the client. Discuss what a retry could repeat.

   Be ready to answer: Does a timeout prove the operation failed? What additional evidence would make retrying safe?

2. Notification fan-out and a slow subscriber

   Open chat server sourceOpen chat client sourceCompare the advanced server

   Connect two clients. Add a delay to one client's server-side writer and send a burst. The basic server has a buffer of 16 messages per client and removes clients whose buffer fills. Choose a policy: drop events, disconnect slow clients, or retain events for replay.

   Compare the advanced server, which writes to sockets sequentially while holding the client mutex. Trace what a blocked write does to the other clients. Also inspect cleanup: the basic server's normal disconnect path does not close its send channel, so an idle writer can remain waiting.

   Be ready to answer: How do you isolate one slow recipient, and how does it recover missed notifications?

3. Bound concurrent work

   Open TCP server sourceRead the worker-pool section

   The server listens on port 9000 and starts a goroutine for each connection. Open several connections that send nothing. Add a small concurrency limit and a read deadline, then decide whether excess clients wait or are rejected.

   Be ready to answer: Where does overload accumulate, and what resource does each limit protect?

4. Graceful shutdown during delivery

   Open shutdown sourceRead the shutdown section

   Add a slow handler. Stop the server while requests are running. Repeat with a handler that takes longer than the 15-second shutdown budget. Observe which work finishes and which work needs a durable record for recovery.

   Be ready to answer: What happens to in-flight notifications during deployment? What happens when graceful shutdown is impossible?

5. DNS caching and stale addresses

   Open cache sourceRead the cache section

   Substitute a controllable lookup function. Change its answer while the previous result remains cached, then expire the entry. The example uses fixed 60-second success and five-second failure durations; it does not obtain those TTLs from DNS.

   Be ready to answer: Who may still use the old address after its mapping changes? What makes reuse safe?

How to run the exercises

Open a terminal in /Users/carlisiacampos/code/src/github.com/learning/networking-with-go. For the standard-library exercises, run the relevant directory:

GO111MODULE=off go run ./exercises/part2/10-http-server-context

With that server running on 8083, a second terminal can demonstrate a client timeout:

curl --max-time 1 http://127.0.0.1:8083/

The Gorilla chat examples have their own modules. Change into the server directory and run go run .. Start each client in a separate terminal from its own directory with the same command.

cd exercises/part2/13-chat-server-gorilla
go run .

Use the reader's Notes button to record the behavior you observed and the tradeoff you would defend.

Read the examples critically

• The webhook receiver checks for a processed ID, performs the effect, and then marks completion. That leaves a concurrent-duplicate risk and a crash window. Explain the atomic boundary instead of treating this sequence as sufficient deduplication.
• The queue example saves an order and then enqueues work. Ask what survives a crash between those two steps. Consider a durable outbox or another reliable handoff.
• The SSE broker drops events for slow subscribers. A current-state hint still needs a later refresh or resynchronization path. Redis Pub/Sub alone does not provide durable replay. Redis delivery semantics.
• A cancellation signal does not wait for the work to stop. Use cooperative cancellation and an explicit completion signal when you need to prove cleanup. Go cancellation contract.

This is a curated interview study route. The linked chapters and source files remain the book's learning material; the experiments are additional practice suggestions.