Topic 1: Module 9 at a glance

By the end of this module, you'll have:

• The notes server running as two stateless replicas behind a round-robin load balancer, with both 2026-07-28 and legacy 2025-11-25 clients served correctly, and multi-round-trip calls that survive landing on a different replica.
• A per-client token-bucket rate limiter that returns real 429 responses, a server-side deadline for tool calls, and a graceful shutdown that finishes in-flight work.
• One OpenTelemetry trace that follows a question from the host, through the MCP server, into a downstream HTTP API, plus a redacting log filter (with tests) that keeps tokens, secrets, and personal data out of your logs.
• A bulk import tool that reports progress, honors cancellation, checkpoints after every note, and uses an idempotency key so a retry after a crash never writes a note twice.
• A validated server.json for the MCP Registry, a checklist for vetting third-party servers, and a small tool-contract checker that tells you whether a change needs a major, minor, or patch release.
• Honest latency and throughput numbers for one replica versus two, measured on one machine and labeled as such.

Prerequisites: Modules 1 to 8. In particular: Streamable HTTP and the two protocol eras (Module 2), Multi Round-Trip Requests (Module 4), progress and cancellation in handlers (Module 5), the host and its agent loop (Module 6), token verification (Module 7), and tool pinning (Module 8). You should be comfortable running a process in the background and reading its log.

Where we are: Module 8 made the notes assistant safe to use: pinned tools, approval gates, and a clear threat model. It still ran as one process on one laptop. This module turns it into something you can deploy and operate: several copies behind a load balancer, protected from bursts, observable end to end, and published with a version contract other people can rely on.