Relay on Lorbic

Designing a Usage-Based Billing Pipeline for SaaS

Sat, 01 Aug 2026 17:26:52 +0530

In How Multi-Tenant SaaS Actually Works, I left one major promise unfulfilled at the end: “Billing is an entire system design on its own. The billing pipeline gets its own post.”

API Design for Backend Systems

Sun, 26 Jul 2026 19:00:00 +0530

A few weeks ago I designed Relay, a multi-tenant AI API gateway, as a system design exercise. That post covered the database, the auth, the billing. It did not cover the thing every one of those systems is sitting behind: the API itself.

Here is the question that post left open. When someone builds GET /v1/requests to list a tenant’s API call history, what should that endpoint actually look like? Offset or cursor pagination? What does the response envelope contain? What happens when Relay needs to add a filter that does not fit in a query string? What does a webhook payload look like when Relay tells a tenant “your batch job finished”? None of that is specific to AI gateways. It is the same decisions every backend API makes, made badly often enough that “REST API” has become a phrase that means “JSON over HTTP, structure unspecified.”

How Multi-Tenant SaaS Actually Works

Wed, 01 Jul 2026 00:00:00 +0530

For the past month I have been reading about multi-tenant SaaS architecture. Not as an academic exercise. I kept running into the same questions on every project I looked at: where exactly does tenant data go, how do you stop one customer’s bug from becoming every customer’s problem, how does billing actually work at the database level. The blog posts I found were either too abstract or skipped the hard parts entirely.