Ten-plus affiliate communities folded into one multi-tenant service
The same feature was being built in more than ten places at once. I merged them into one codebase and cut traffic over one DNS record at a time.
- React
- TypeScript
- Node.js
- EC2
- Route 53
- Auto Scaling
Specification
- Organisation
- Nudge Healthcare
- Period
- 2024 – 2025
- Scope
- 10+ affiliate community services
- Environment
- A mega-app containing 15+ sub-services
- Stakeholders
- Product, backend, Android, iOS, QA and operations — 50+ people
- Cutover
- Per-service DNS record, one at a time
- Role
- Frontend development, consolidation architecture, migration
Context
Each affiliate's community ran on its own codebase and its own environment. More than ten services were building and maintaining the same features independently.
Changing one shared feature meant editing several repositories and deploying each of them. Requirements, release cycles and operating practices differed per service, so the blast radius of any change was hard to predict.
Approach
I separated shared behaviour from per-service behaviour, reshaped the codebase so several tenants run from it, and pushed the differences into feature flags and configuration.
Each organisation's requirements were re-sorted into shared and individual. What could not be generalised stayed as configuration; what could was merged into one spec.
The existing EC2 environments stayed up while I prepared the unified server. Nothing was switched all at once: services moved one DNS record at a time, and any single service could be pointed back at its old environment.
Once traffic converged on one structure, resource usage rose. Auto Scaling absorbed the increase.
I aligned API contracts, schedules and dependencies with product, backend, mobile and operations. With 15+ sub-services in the mega-app, release cycles and change impact had to be coordinated alongside the code.
System
One service per cutover, with the path back left open.
Each service's traffic passes through a Route 53 record. Records were moved one at a time from the legacy EC2 instances to the multi-tenant server, and any single record could be pointed back. An Auto Scaling group sits behind the unified server.
Measured
Before: 10+After: 1
Shared features are now changed in one place.
~20%
Maintenance headcount, relative to before consolidation.
15+
Release cycles were coordinated per service inside the mega-app.
Boundaries
- Backend APIs and the mobile clients belonged to other teams. I owned the frontend consolidation structure and the migration procedure.
- Final decisions on which requirements to generalise were made together with product and operations.
- Zero-downtime migration was the goal the sequential cutover and rollback path were designed to reach; the unit of cutover was one service.