💡 Target Audience: CTOs and Senior Engineers focused on cloud architecture and cost optimization at scale.

Run communication infrastructure long enough and you meet the same wall twice. First, outbound transfer starts costing several times more than storage. Second, latency stops being an average and starts being a distribution — the p50 looks fine while the p95 quietly ruins the experience for a tenth of your users.

This post is about the two design decisions we made in response, how we measure whether they worked, and — just as importantly — what we do *not* claim.

Decision 1: media is served at the edge, and transfer is not metered

The economics of media in chat are counter-intuitive. Storage is billed once per month; delivery is billed once per view. A single popular attachment can cost more to serve in a week than to store in a year, and you cannot predict in advance which attachment that will be.

Our position is that a customer should never have to model that. So:

• Uploaded media is stored once and served from the edge location nearest the requester, not from a single origin region.
• Outbound transfer is not metered at all — on any plan, including the free tier. Storage above quota is $0.03/GB on paid plans — Free stops new uploads at its quota instead — which prices *holding* data rather than *serving* it.
• The variable that drives your bill becomes library size, which you control, instead of popularity, which you do not.

For a customer, the practical test is simple: take last month's outbound GB and multiply by your current provider's rate. That entire line item goes to zero and stays there.

Decision 2: the critical path stays inside one region

A message that travels Seoul → central database → Seoul pays for the round trip twice. So the hot path — connection state, channel membership, message fan-out — is handled in the region the user connected to. Cross-region propagation happens off the critical path, asynchronously, so a user in Frankfurt is never waiting on a lookup in Virginia to see their own message appear.

The trade-off is explicit and worth stating plainly: cross-region consistency is eventual, on the order of the network round trip between regions. For conversation, presence and delivery ordering within a channel, that is the correct trade. For workloads that need strict global linearisability, it is not — and you should choose accordingly.

How we measure — and how you should verify

A single latency number in a marketing table is close to meaningless without its measurement conditions. Here are ours:

Three honest caveats:

1. Cross-continent pairs are bounded by physics. Seoul ↔ São Paulo will not be 65 ms on our platform or anyone else's. Light in fibre plus routing is the floor, and no architecture negotiates with it.
2. Averages hide the problem. If a vendor quotes only an average, ask for p95 — that is where a bad architecture shows.
3. Reproduce it yourself. Instrument publish-to-receive in your own app, from your own users' devices, before any vendor's number (including ours) enters a decision document.

What we deliberately do not claim

• We do not claim a fixed number of regions or points of presence. Those numbers change, and a vendor's PoP count is not a proxy for *your* users' latency — your traffic's geography is.
• We do not claim strict global consistency. See Decision 2.
• We do not claim zero cost. We claim **zero *transfer* cost**, with everything else published as a rate card rather than quoted per deal.

What this buys you as a customer

• A bill you can model a year out. Every rate is published; nothing is per-user; transfer is free.
• A latency profile that does not degrade as you add regions of users — because their sessions terminate near them rather than at a single origin.
• No architectural work on your side. There is no CDN to configure, no cache-invalidation policy to own, no origin shield to tune. Upload a file, share it, done.

The 30-second version

Two decisions: serve media at the edge and stop metering transfer; keep the real-time critical path inside one region and reconcile across regions asynchronously. The first makes cost predictable, the second makes latency predictable — and both are worth exactly as much as your own measurements say they are.