I just had a meeting with a potential client running a pre-built Magento-based solution from another company, and the infrastructure underneath it was a monument to premature scaling. The solution was deployed on a full AWS cluster: a separate RDS database, an EC2 instance for Magento, a standalone server for the cron jobs, Redis on its own node, Elasticsearch on its own node. Everything horizontally separated, everything billed separately. This cluster cost more than $2,000 a month, and it was the staging environment. Not production. The rehearsal space.
And after all of that, the pages were slow. Multiple seconds to load, on a setup whose architecture diagram looked like it was built for a retailer fifty times their size. It is tempting to blame the technology or the server when you see numbers like that, but the real lesson is simpler. It is about the right solution for the right time, and this was the wrong solution for this time.
MageCloud Infrastructure Note
What Downscaling Actually Looks Like
THE PATTERN WE KEEP FINDING
$4,000+ monthly AWS bills
Over the last two months we downscaled three clients who were each paying more than $4,000 a month to AWS for distributed clusters their traffic never justified.
WHERE THEY LANDED
£700-800 a month on one VPS
A single properly configured VPS, handling the same stores and the same traffic comfortably. Same platform, same catalogue, roughly a fifth of the cost.
THE RULE
Vertical first, horizontal later
Resize one machine as you grow. Distribute across machines only when a single machine genuinely cannot carry the load. Most stores never reach that point.
Paul Ryazanov · MageCloud · we make infrastructure boring and cheap
Why Slow Pages on Expensive Clusters Are So Common
The counterintuitive part of this story is that the $2,000 cluster was slow. People assume cost buys speed, but distribution has its own physics. Every component on its own node means every page request crosses the network several times: app server to database, app server to Redis, app server to Elasticsearch. Each hop adds latency that simply does not exist when the services share a machine. A distributed architecture pays that latency tax in exchange for the ability to scale components independently, which is a brilliant trade when you need it and a pure cost when you do not.
A single well-configured VPS keeps all of those conversations on localhost. For the traffic levels most ecommerce stores actually see, including successful seven-figure stores, that setup is not the budget option. It is the faster option. The cluster only wins when traffic genuinely exceeds what one machine can serve, and modern machines are very large.
The Day-One Scalability Myth
The expensive mistake almost never happens at the infrastructure level. It happens earlier, in the sentence “we want it to be scalable from day one.” That sentence sounds like prudence and prices like fear. It buys horizontal architecture, with its node-by-node billing and its devops overhead, as insurance against a traffic level the business has not earned yet and may never see.
You do not have to build scalable infrastructure from the start. Make it good enough, and I mean specifically: good enough to run on one machine, configured properly by someone who knows the platform. Vertical scaling, simply resizing the instance when you need more capacity, will keep a growing store healthy for a long time. The resize takes minutes. The moment a single machine genuinely cannot carry you is a real milestone with real revenue attached, and that is the right day to design the cluster, because that is the day you finally know what the actual bottleneck is. Until then, the cluster is cosplay. The money is real, though, which is why infrastructure review is one of the first places we look when cutting hosting costs for clients.
Who Benefits From Your Oversized Setup
It is worth asking how the oversized setups happen, because they happen constantly. Part of it is vendor incentive: the company selling the pre-built solution looks more enterprise when it deploys onto an enterprise-shaped diagram, and the hosting bill is not their problem. Part of it is engineer incentive: distributed systems are more interesting to build and better for the CV than one well-tuned VPS. And part of it is the founder’s own ego, because “we run on a cluster” sounds like success.
None of those incentives belong in your infrastructure decision, the same way a vendor’s revenue predictability does not belong in your contract length. The only question that matters is what your actual traffic, today and one resize from today, requires. Answer that with data from your own analytics, not with the architecture diagram that impressed you in the sales deck.
The Trade-Off I Will Admit To
There are stores that genuinely need horizontal architecture, and I want to be precise about which ones. Stores with traffic spikes a single machine cannot absorb, flash-sale businesses, television-advertised brands, marketplaces with heavy concurrent write load. Stores with compliance or uptime requirements that mandate multi-node redundancy. If that is you, build the cluster, staff for it, and pay for it knowingly. The argument here is not that clusters are wrong. It is that they are a specific tool for a specific scale, and most of the merchants paying for them are paying for the diagram, not the need.
The Twenty-Minute Check
If your monthly infrastructure bill has a comma in it and your store is not doing flash-sale traffic, the check is worth twenty minutes. Pull your real concurrent traffic numbers, look at what one modern VPS handles, and price the difference. We did that three times in the last two months and found roughly $40,000 a year of waste across the three stores. If you want the same look at your setup, get in touch. Bring the AWS bill. It is usually the most persuasive document in the meeting.
Related reading: When Google Merchant Center Rejects Working Images. Another case for boring infrastructure: the fancy CDN that fed Google different images than humans.