Slack Flannel Edge Cache Lab (Interactive)
Absorb the 9 AM launch storm at the edge or watch 200 boot queries melt MySQL pools. Every client boot fires hundreds of queries for channels, rosters, and presence. Serve the workspace graph from Flannel's edge RAM in under a millisecond, or funnel the storm straight into core databases.
Flannel Edge Cache & Boot Storm Lab
Every morning, tens of millions of workers launch Slack at once. Absorb the boot storm with edge-cached workspace graphs — or send it straight to sharded MySQL.
How It Works Under the Hood
Slack's workload has a brutal morning shape: tens of millions of desktop clients boot within an hour of 9 AM, each demanding metadata for 50 channels, rosters of thousands of teammates, unread counters, and custom emoji — roughly two hundred queries per launch. Flannel, an application-level caching proxy at regional edge points of presence, answers boot bundles from in-memory workspace graphs in under a millisecond and multiplexes thousands of client WebSockets into a small pool of core connections. Kafka invalidation streams keep the edge honest in under 50 milliseconds, and lazy presence subscriptions defuse the O(N^2) fan-out of 50,000-person workspaces.
Core Architectural Principles
- Boot-storm load: launches per minute times ~200 queries each, compared against the connection-pool ceiling of sharded Vitess MySQL.
- Edge multiplexing: Flannel terminates millions of client WebSockets and forwards over a few thousand pooled core connections.
- Presence fan-out: eager status broadcast grows as N^2 per workspace; lazy subscriptions bound it to on-screen colleagues.
For enterprise-collaboration designs, identify the boot payload first: "Launching a client is 200 reads; cache the whole workspace graph at the edge." Credit Flannel by name, then handle presence as its own scaling problem: subscribe lazily to visible members or explain the N^2 blast radius. Mention hot shards — a 300,000-user workspace on one Vitess shard is the follow-up question you should pre-empt.
Edge-cached workspace graphs crush boot latency and database load but pin enterprise data in edge RAM and need real-time invalidation streams to stay fresh.