Slack Flannel: Caching at the Edge for a Chat Client
also called Flannel
Slack pushed user and channel metadata into an application-aware edge cache because clients were downloading enormous amounts of it on every connection.
The problem
When a Slack client connects, it needs metadata to render anything: the users in the workspace, the channels, their membership. For a small team that is trivial. For an enterprise workspace with tens of thousands of users and thousands of channels, it is a very large payload — sent on every connection, to every client, from a distant region.
The cost was borne three ways: slow start-up for the user, heavy load on the backend, and substantial bandwidth.
What they did
Flannel is an application-level cache deployed at edge locations. Rather than the client downloading the full workspace metadata, the edge cache holds it and answers the client's specific queries — resolving a user id when a message mentions someone, providing channel details as the user navigates.
The critical property is that it is application-aware. A generic HTTP cache cannot help here, because the requests are not cacheable in the conventional sense — they are per-user, authenticated, and the underlying data changes. Flannel understands the domain: it knows what a user object is, it can be updated by the backend when one changes, and it can serve a query it has never seen before from data it already holds.
The client model changed accordingly: from "download everything up front" to "fetch what is needed, on demand, from something nearby".
The trade-off
An application-aware cache is a stateful service in the request path with its own invalidation logic, its own failure modes, and its own consistency questions — how stale may a user's display name be, and what happens when the cache is unreachable.
It is substantially more complex than a CDN and substantially more capable.
The transferable lesson
Examine what clients actually need before optimising how it is delivered. The original design sent everything because it was simple; the insight was that a client needs a small, unpredictable subset, and the fix was to make that subset cheap to fetch rather than to compress the whole.
And the general point about edge caching: CDNs cache responses; they cannot cache a domain. When the data is personalised, authenticated and query-shaped, an application-aware cache at the edge is the tool — and it is a real service to build and operate, not a configuration change.