Most infrastructure problems that take a storefront down aren't exotic. They're ordinary scaling limits, hit for the first time, during the one week traffic actually shows up: a launch, a marketing push, a sale. Increddy is built to handle well over a million monthly visitors, and the interesting part isn't the number, it's that the architecture was sized for it before the traffic existed to prove it was needed.
Designing for traffic you don't have yet
There's a real tension here worth naming honestly: over-engineering for traffic that never comes wastes budget and adds complexity nobody uses. Increddy's case is different because the business runs paid acquisition deliberately and at volume, which makes "what happens at 10x current traffic" a near-term planning question, not a hypothetical. Where the traffic forecast is real, sizing the architecture ahead of the need is cheaper than retrofitting it mid-spike, when every hour of downtime has a clear cost attached.
Horizontal scaling: EC2 behind an ALB
The backend runs on AWS EC2 instances behind an Application Load Balancer, built for horizontal scaling rather than one larger box. That choice matters for more than raw capacity: a single large instance is a single point of failure, where an ALB distributing load across multiple instances keeps the storefront up through an instance failure or a rolling deploy, not just through a traffic spike. Autoscaling policies add capacity as load increases and remove it as load drops, so the infrastructure cost tracks actual usage instead of a fixed worst-case provision sitting idle most of the month.
Redis as the event bus, not just a cache
Redis shows up twice in this stack: as a conventional cache, and as the backbone of Medusa's workflow engine and event bus. That second role is the one that matters for scale. Commerce events like order placement and payment capture are processed asynchronously through that event bus rather than as blocking, synchronous steps in the request path, which is what lets the checkout flow stay fast under load instead of having its response time tied to however long every downstream side-effect takes to finish.
Planning for traffic your current infrastructure hasn't been tested against?
Tell us your actual growth or campaign plans. We'll tell you honestly which parts of your stack need sizing now versus which can wait.
Talk to an engineer →Cloudflare Workers at the edge
In front of the backend, Cloudflare Workers run at the edge, close to the visitor, ahead of the origin. The distinction that matters here is between caching static assets and running logic: a Worker can handle or short- circuit a request before it ever reaches the EC2 fleet or Postgres, which takes load off the origin for exactly the kind of request pattern a global, paid-acquisition-driven storefront generates, bursty, geographically spread, and disproportionately hitting the same popular product pages a campaign is currently pointed at.
The rule
Treat scaling shape, horizontal versus vertical, sync versus async, cached-at-the-edge versus always-hitting-origin, as an architectural decision made once, deliberately, not a setting tuned reactively after an incident. Size for the traffic the business plan actually implies, not for an arbitrary safety margin, and build the asynchronous paths in from the start, because retrofitting "this should have been a background job" into a synchronous request path under load is far more expensive than designing it that way from day one. For the commerce logic running on top of this infrastructure, see how we made Increddy's key delivery idempotent under concurrent events. We design and size backends like this under Medusa development and headless commerce engagements.