Case study 032023
Monolith to Multi-tenant Platform
A zero-downtime, strangler-fig migration of a nine-year-old monolith across three product teams.
- Role
- Architect
- Team
- 3 product teams
- Timeline
- 11 months
- Focus
- Platform, Backend
60 → 8 min
deploy time
99.98%
uptime through the migration
3
enterprise deals unblocked
The problem
Deploys took an hour, one noisy tenant could slow everyone down, and enterprise deals stalled on data-isolation requirements. A rewrite was off the table: the product had to keep shipping throughout.
What I owned
- The migration RFC and the sequencing that three teams signed up to.
- The tenant-aware routing layer at the edge.
- The TypeScript service template: auth, tracing, health checks and CI, used by every new service.
- The dual-write and checksummed backfill tooling for tenant moves.
Key decisions
- 1
Strangle, don't rewrite
Routes moved to new services one at a time behind the edge router, and each could be rolled back with a config change.
- 2
Isolate by tenant size
Only the largest tenants needed their own schema. Everyone else stayed pooled, which kept operations simple where isolation wasn't paying for itself.
- 3
A paved road before new services
The service template shipped before the first extraction, so every new service had the same observability and deploy story from day one.
Outcome
The platform now deploys in minutes, noisy tenants are contained, and sales can offer data isolation as a standard enterprise feature.
- TypeScript
- Node.js
- Ruby on Rails
- PostgreSQL
- Terraform
- AWS