Inside Atlassian’s Forge Billing Architecture for Distributed Usage Tracking at Scale

Justy Okay so Atlassian finally wrote up the engineering behind Forge Billing and I think this is the kind of thing where the marketing version is 'usage-based pricing at scale' but the actual story is — somebody has to turn a million scattered events into one billable number without dropping anyone on the floor.

Cody Right.

Justy And they basically rebuilt their ingestion layer because the old extension model didn't actually know how much anything was being used.

Cody Yeah, which is funny because the moment you go usage-based you suddenly care about every function invocation, every byte of storage, every telemetry blip — and those signals live in like twenty different services that don't talk to each other.

Justy Which is where UTS comes in.

Cody Yeah. UTS is the part of the post I actually read twice. They call it the nervous system, which is engineer-speak for 'this is where it all has to be right or the bill is wrong.' It's the layer that validates, normalizes, enriches, and — the part I care about — attributes every event to the correct entitlement and subscription before anything downstream sees it.

Justy What actually breaks if attribution is wrong? Like what's the failure mode they're designing against?

Cody So imagine tenant A's function invocations get attributed to tenant B's subscription. Now tenant B gets billed for compute they didn't run, tenant A under-bills, and your finance team is fielding tickets from both sides. And worse — if you only catch it at month-end reconciliation, you've got a write-down problem, not a bug fix.

Justy Right, right. So the cost of getting attribution wrong isn't a 500 error, it's a customer trust problem.

Cody Exactly. And the way they handle it is — they say it explicitly, which I appreciate — every event has to fit the UTS contract before it continues. Schema validation at the streaming layer, Kafka under the hood, internal delivery abstractions on top. So producers and consumers don't have to know about each other, which means you can scale ingestion independently from the billing side.

Justy Mm-hm. That's the part that made me think this is more than a billing post — it's an event-platform post wearing a billing costume.

Cody Yeah. The billing part is downstream. The actual hard engineering is the streaming and the idempotency.

Justy Which they handle how?

Cody Idempotent event design plus time-based aggregation. So duplicates from retries don't double-count — the event itself carries enough identity that the system can recognize 'I've seen this one.' And late-arriving events get folded in through windowed processing instead of being dropped, which matters because distributed systems are basically late-event delivery services with extra steps.

Justy 'Late-event delivery services with extra steps' is going on a shirt.

Cody And then there's a real split in storage — immutable long-term for audit, low-latency analytical layer for dashboards and APIs. Which is the right call because auditability and query latency are different problems with different storage shapes.

Justy If you're a product team shipping usage-based anything, the thing I'd actually steal from this is — don't try to make your billing system smart. Make your event-attribute layer smart and let billing be dumb and correct.

Cody Yeah. And the other thing — the per-app attribution mapped to developer spaces, that's the part that matters for transparency. Customers can see what they're being charged for, which is the only way usage-based pricing doesn't become a trust crater.

Justy Alright, I'll link the post. Cody, you surviving the week?

Cody Barely. It's Monday, the bar is on the floor.

Justy See you Wednesday.