Context & Pain Points
The business ran two applications that customers saw as one. Magento served the storefront, and a Node.js service answered API calls from the web and the mobile app. They had different runtimes, different databases and very different traffic shapes, yet they had been released together, so a change to one API meant a coordinated release of everything. The environments had been built by hand at different times. Instance sizes, PHP settings and cache configuration had drifted apart between staging and production, and a bug that only showed up in production was hard to reproduce anywhere else. Scaling was blunt as well. When the API got busy, the only lever added capacity to Magento servers that were sitting idle.
What We Had To Solve
- Giving two applications one front door. Shoppers and the mobile app reach Magento and the Node.js API through the same domain. A single entry point had to send each request to the right fleet without tying their releases together.
- Scaling the API without scaling the store. API traffic and storefront traffic peak at different times. Capacity had to follow whichever one was busy instead of growing both every time.
- Keeping two very different data stores available. Magento needs a relational database and a fast cache. The Node.js services keep their data in MongoDB. Each store needed a copy that survives the loss of an instance or a zone.
- Keeping environments honest once they were no longer hand-built. Any setting that lived only on a running server, and not in version control, would drift again within weeks.
- Releasing one application without waiting on the other. A change to an API endpoint should not have to queue behind a Magento release, and the reverse.
How We Built It
- Put a web-server Auto Scaling group behind one internet-facing load balancer. It routes storefront traffic to an internal load balancer in front of Magento, and API traffic to a separate internal load balancer in front of Node.js.
- Gave Magento and Node.js their own Auto Scaling groups, each spanning both Availability Zones, so a busy API adds Node.js instances and leaves the Magento fleet alone.
- Ran Magento on Amazon RDS with a read replica in the second zone and ElastiCache Memcached in front of it. The Node.js tier got a three-node MongoDB replica set on EC2, so a lost node hands over to a secondary instead of taking the API down.
- Sent database backups to S3 and put CloudFront in front of the web tier for static content, so repeat asset requests stop at the edge.
- Wrote Terraform modules for the VPC, load balancers, Auto Scaling groups, RDS and ElastiCache, then drove staging and production from the same modules with different variable files. GitHub Actions builds and deploys each application to its own Auto Scaling group on its own pipeline.
Outcomes That Mattered
70% Faster Releases
Application release cycles went from weeks to minutes, because each application ships on its own pipeline instead of waiting for a coordinated release of the whole stack.
Independent Scaling
Magento and Node.js scale in separate Auto Scaling groups, so a busy API 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 runs in one VPC across two Availability Zones on EC2. Route 53 resolves the domain to an internet-facing load balancer in front of a web-server Auto Scaling group, and CloudFront serves static content from the same origin. The web tier hands each request to one of two internal load balancers. One fronts the Magento Auto Scaling group and the other fronts the Node.js Auto Scaling group, and both groups span both zones. Magento reads and writes Amazon RDS, with a read replica in the second zone, and keeps its cache in ElastiCache Memcached. The Node.js services store their documents in a three-node MongoDB replica set on EC2. Database backups land in S3. Terraform builds every environment from the same modules, and GitHub Actions ships each application on its own pipeline.