TCP# 105: The Multi-Tenant Architecture I'd Never Build Again
Nine tenants. Eleven services. One pooled model. This is what we got wrong.
You can also read my newsletters from the Substack mobile app and be notified when a new issue is available.
We built a shared-everything multi-tenant platform on AWS.
One database per service. Tenant data separated by row-level filters. One deployment pipeline. One observability stack. One set of IAM roles scoped to the service, not the tenant.
It looked clean on a whiteboard.
It did not survive contact with production.
This is what we got wrong, what it cost us, and what I would build instead.
THE INCIDENT THAT EXPOSED EVERYTHING
Eighteen months after launch, a single tenant’s batch job consumed enough database connection pool capacity to degrade response times for every other tenant on the platform.
No data breach. No data loss.
Just one tenant’s workload bleeding into every other tenant’s experience.
Leadership called it a performance issue.
