Running a shared platform once customers depend on it: per-tenant visibility, fair background work, online migrations, availability reporting, and cost.
These guides cover the day-to-day operation of a multi-tenant platform. Most of their labs are simulations with every parameter in the code, so you can replace the invented traffic with a day or a month of your own and rerun them. If you only read one, read the job queue guide: its lab shows a commonly published scheduler that never served a second tenant and then stopped entirely.
Find one tenant's slow requests in traces and logs without exploding metric cardinality.
Lab finding: None by default, although the header reached the downstream service. With a span processor copying tenant.id from baggage, all three spans carried it.
Keep one tenant's batch from delaying everyone else's background jobs.
Lab finding: FIFO: 24.9 s. The published dispatcher never ran the other tenants' jobs and then looped forever. Corrected DRR: 40 ms.
Change the schema without letting a waiting lock stall the application.
Lab finding: No lock_timeout: 7,500 of 12,000 queries failed. A 500 ms lock_timeout with retries: none failed, worst wait 490 ms, migration done 2.5 s after the report.
Detect outages the way customers see them and measure availability as the contract defines it.
Lab finding: At 99.9%, February allows 40 min 19 s and 31-day months 44 min 38 s. Bands '99.0-99.89%' and '99.9-100%' matched nothing for 2,600 to 2,851 s of monthly downtime.
Attribute shared infrastructure cost to tenants with rules you can defend.
Lab finding: One tenant ranged from a 54% margin to -245%. An equal split showed small tenants at -40% as a group. Keeping idle capacity separate removed $11,400 from tenant costs.
Put numbers on it: Multi-Tenant Capacity Planner
Attributing shared cloud cost to tenants is a set of choices. A worked lab shows one tenant's margin moving from 54% to -245% depending only on the allocation rule.
Host the status page outside your failure domain, probe what customers actually do, and measure availability as the contract defines it. A lab finds a gap in a common credit table.
Why one tenant's batch delays everyone in a shared queue, how deficit round-robin fixes it, and a lab in which a commonly published DRR dispatcher never served a second tenant.
Put the tenant ID on traces and logs, keep it out of metric labels, and know that baggage does not reach your spans by itself, as a Go lab with OpenTelemetry shows.
Which PostgreSQL changes block reads or writes, why a fast ALTER TABLE can stall an application for minutes, and how to stage column changes safely.
