Infrastructure debt at the worst possible moment
Fast-moving engineering teams often build for the users they have today, not the users they will have in 12 months. A monolithic API on a single EC2 instance is a reasonable choice for an early-stage product — until you need to scale. The challenge is that the migration from that setup to a horizontally scalable architecture cannot wait for a convenient window.
The harder constraint in most cases: you cannot take the platform offline for a full rebuild. Revenue is live, users are active, and any downtime is a reputational or regulatory risk. The strangler-fig pattern is the industry-proven solution — carve out services incrementally, migrate traffic gradually, and keep the original system live throughout.
Key pain points
- ✕Single-server setup with no horizontal scaling path
- ✕Database connection pooling issues causing cascading failures under load spikes
- ✕Deployment requiring maintenance windows, blocking release cadence
- ✕No observability — first sign of a problem is a user complaint
- ✕Database read/write contention blocking query performance at scale
Strangler-fig migration to Kubernetes, zero downtime
The reference architecture implements a strangler-fig pattern: new services are carved out of the monolith one at a time, containerised, and moved to EKS (Elastic Kubernetes Service) behind an ALB. The monolith remains live throughout, handling only the traffic not yet migrated. No big-bang cutover — every step is independently deployable and reversible.
The database migration is the highest-risk step. The pattern we use: set up a PostgreSQL read replica on RDS Aurora, gradually shift read traffic to it, then migrate write traffic using a dual-write pattern with a validation window before cutting over fully. Zero data loss, zero downtime, with instant rollback capability at every stage.
Datadog is our observability layer of choice for this architecture — APM traces, infrastructure metrics, log correlation, and custom SLO dashboards. This is often the first time engineering teams get real-time visibility into latency percentiles, error rates, and database query performance.
Technology stack
Container Orchestration
Database
Infrastructure as Code
Observability
Application
Key engineering decisions
EKS over ECS
We recommend EKS despite its higher operational complexity when the client's team wants to build Kubernetes expertise internally. ECS is faster to set up but creates a skill dependency that limits the team's portability long-term.
Aurora Serverless v2 for the database
Aurora Serverless v2 auto-scales compute capacity in 0.5 ACU increments — critical for applications with spiky traffic patterns (payroll dates, campaign launches, month-end). Provisioned RDS requires over-provisioning at significant ongoing cost.
Feature flags for traffic shifting
Every new service rollout should use feature flags for surgical traffic percentage control during migrations. This eliminates maintenance windows entirely and allows instant rollback without a deployment.
Why this architecture
This is our reference architecture for infrastructure modernisation engagements. The strangler-fig pattern and dual-write database migration are well-established in the industry; the specific tech choices (EKS, Aurora, Datadog, Helm) reflect what we consider the current best defaults for AWS-hosted Node.js applications. Every engagement starts with a two-week infrastructure audit before any migration work begins.
A note on our approach
Infrastructure migration is one of the highest-stakes engagements a team can take on. Our founder has extensive experience with exactly this problem across multiple enterprise environments. This architecture document is our starting point — we adapt it based on the specific platform, stack, and risk constraints of each engagement.
Interested in building this?
Every engagement starts with a two-week discovery sprint. We assess your requirements, existing stack, and data readiness — then give you a concrete build plan and cost estimate.
Book a discovery callMore engineering work
