intermediate 2 min answer

A content platform must decide what runs at the edge, in a region, and centrally. How should the topology be reasoned about?

sharechattopologyedgeregionalcentral
Show the full answer Hide the answer

The reasoning

Place each component by what it depends on, not by how fast it should be.

  • Edge: anything depending only on the request and cached or replicated data. Content delivery, routing, authentication from a signed token, personalisation of cacheable content, request filtering.
  • Regional: anything needing low-latency access to data that can be replicated per region, or that must stay in a jurisdiction. Feeds, recommendations serving, media transcoding for a region's uploads.
  • Central: anything with a global invariant, anything requiring consistency across regions, and anything whose data is genuinely global. The authoritative user record, moderation decisions, aggregate analytics.

What the split costs

  • Data movement between tiers, which is latency and cross-region charges — frequently a substantial and invisible share of the bill.
  • Consistency reasoning at each boundary, since each tier has a different view.
  • Operational surface, multiplied by the number of tiers and regions.
  • Debugging across tiers, which requires correlation that must be built deliberately.

The content-platform specific shape

Media delivery is the dominant cost and is trivially edge-cacheable, which makes the edge tier's value overwhelming — cache hit ratio is a direct margin consideration, improved by origin shielding so a miss in many locations is one origin request, request collapsing, and consistent URL construction since query-string variation is a common silent cache-buster.

Moderation is central, because a decision must be consistent globally and because the model and the policy are shared.

Feeds are regional, since they depend on data that can be replicated per region and the latency matters.

The takedown requirement that crosses all tiers

A removal must reach every cache tier quickly, which conflicts with the long TTLs that make delivery cheap.

A purge path separate from ordinary invalidation — fast, confirmed, by tag rather than by URL so all renditions are removed, with the origin failing closed as the backstop — is what buys back the ability to use long TTLs, and without it the choice is between expensive delivery and content remaining available after removal.