Context & Pain Points
A single Magento deployment carried the storefront, the admin panel and every custom API as one release unit. Changing one Node.js service meant redeploying the whole application, so teams that shared nothing but a repository queued behind each other and one bad merge held up everyone. Environments made it worse. Dev, staging and production had been built by hand at different times, so PHP settings, cache configuration and instance sizing had drifted apart, and a bug that only showed up in production was hard to reproduce anywhere else. Scaling was just as blunt: the whole stack scaled together, so a traffic spike on one API path forced capacity onto Magento processes that were sitting idle.
What We Had To Solve
- Splitting the monolithic database without a distributed lock. Every part of the application wrote to one schema, with foreign keys crossing what should have been service boundaries. Separating it meant deciding table by table which service owned the write path and which ones could work from a read copy.
- Standardizing container builds across independent teams. Each team had its own Dockerfile conventions, base images and environment variable names, so a service that ran locally often failed its first Fargate task launch. Health check paths and log formats differed too, which made a rolling deploy hard to judge as healthy.
- Sharing hot state across container layers. The Node.js services and Magento both needed the same session and catalog lookups, but once they were separate tasks neither could reach the other's memory. Reading from RDS on every lookup would have moved the bottleneck rather than removing it.
- Keeping three environments honest once they were no longer hand-built. Any setting that lived only in a running container, and not in version control, would drift again within weeks.
How We Built It
- Built a GitHub Actions pipeline per service that lints, tests, builds the image and updates that service's ECS task definition. A deploy touches one service, so a failing build blocks that service and nothing else.
- Wrote Terraform modules covering VPC layout, the ECS cluster, task definitions, RDS parameters and Redis node sizes, then drove dev, staging and production from the same modules with different variable files. Rebuilding an environment is a plan and an apply, not a runbook.
- Put a Redis cluster in front of RDS as the shared lookup and session cache for both the Node.js services and Magento, so any Fargate task can serve any request. RDS stays the system of record and Redis absorbs the repeated reads.
- Gave each service its own CPU and memory reservation and its own scaling target, so an API path under load adds tasks without pulling capacity toward Magento.
Outcomes That Mattered
70% Faster Releases
Application release cycles went from weeks to minutes, because a service ships on its own pipeline instead of waiting for a coordinated release of the whole stack.
Independent Microservice Scaling
Fargate tasks scale per service on real request volume, so a busy API path adds capacity where the load actually is.
Eliminated Config Drift
Every environment is generated from the same Terraform modules, so staging and production stopped disagreeing about settings nobody had written down.
Outcome
The platform now runs as separate Node.js services and Magento core engines, each packaged as its own container image and scheduled on ECS Fargate. Terraform builds every environment from the same modules, so dev, staging and production differ only by a variables file. A Redis cluster holds shared session and lookup state, which lets any task serve any request instead of pinning a user to a host. Releases ship per service through GitHub Actions rather than as one coordinated event.