"You aren't gonna need it."

It's one of the best rules in software, and we broke it on purpose.

Increddy's backend is built to handle well over a million monthly visitors, and we built it that way before the traffic existed to justify it. Here's why that wasn't gold-plating, and where we drew the line.

When YAGNI stops applying

Over-engineering for traffic that never shows up wastes money and adds complexity nobody uses. That's real.

Increddy is different for one reason: it buys traffic deliberately, and at volume. For a store running paid acquisition, "what happens at 10x traffic?" isn't a thought experiment. It's next month's campaign.

And outages don't usually come from anything exotic. They come from ordinary limits you hit for the first time, during the one week traffic finally shows up:

  • a database connection cap nobody knew about
  • a single instance that doesn't autoscale
  • a cache that was never built

Find any of those during a launch and the good news becomes an incident. Find them on a whiteboard and they cost nothing.

The stack, layer by layer

Edge: Cloudflare Workers. These run close to the visitor, before the origin, and they run logic, not just cached files. A Worker can handle or short-circuit a request before it ever reaches EC2 or Postgres. That matters for paid campaign traffic, which comes in bursts, from everywhere, all aimed at the same few product pages.

Compute: EC2 behind an Application Load Balancer. We went horizontal, not one bigger box. That's partly about capacity, and partly because one big instance is a single point of failure. With an ALB in front of several instances, the store survives an instance dying or a rolling deploy, not just a traffic spike. Autoscaling means the bill follows real usage instead of paying for worst-case capacity all month.

Async: Redis as the event bus. Redis shows up twice. One role is the usual cache. The more important one is that it runs Medusa's event bus and workflow engine. Order placement and payment capture are processed asynchronously, so checkout stays fast under load instead of waiting on every downstream side effect.

Data: Postgres on RDS. Managed, boring, and that's the point.

The mistake that costs the most to undo

If you only take one thing from this post:

Retrofitting "this should have been a background job" into a synchronous request path, under load, is far more expensive than designing it async on day one.

Horizontal vs. vertical, sync vs. async, edge vs. origin: these are architecture decisions you make once, on purpose. They aren't knobs to tune after the post-mortem.

So where's the line?

Size for the traffic the business plan actually implies, not for an arbitrary safety margin. If nobody is planning to send you traffic, YAGNI wins. If someone is about to spend money sending you traffic, build ahead.

This infrastructure sits under a full Shopify-to-Medusa rebuild, including a key-delivery system that can't sell twice. See the Increddy case study on kryeo.com →

The detailed architecture write-up is on the Kryeo blog.

We're Kryeo. We design and size backends like this through our headless commerce work.