Goldratt - Ecommerce Architecture Review
Describe how your online shop is built and how busy it gets, and find out what breaks first when the traffic arrives, and what to fix before it does.
Named after Eliyahu Goldratt, whose Theory of Constraints says a system only moves as fast as its tightest bottleneck. Find that one first.
Ecommerce architecture is how the parts of an online shop fit together: the storefront shoppers see, the platform that holds products and orders, checkout and payments, search, the database, the integrations to stock, ERP and email, and the hosting under all of it. A scalable ecommerce architecture is one where none of those parts falls over when traffic and orders jump, and the one that usually goes first is an integration or the checkout, rather than the platform itself. To review yours, map each layer, find the single tightest bottleneck on the path from product page to paid order, and fix and load test that before your next peak. The tool below does that first pass from a description of your shop.
When a free tool is not enough
Knowing the bottleneck is the easy half.
Fixing it before the traffic arrives is the hard half, usually with a small team and a platform nobody fully understands any more. Our fractional CTOs look at the actual code, hosting and integrations, load test the parts that matter and get the fixes shipped in the right order. If you are weighing a replatform, we will tell you honestly whether the platform is the problem.
How to use Goldratt, the Ecommerce Architecture Review
Describe how the shop is built
The platform and version, where it is hosted, and everything connected to it: payments, search, stock and ERP, email, apps or extensions, CDN. Name the products if you know them. Up to 3,000 characters.
Say how busy it gets
Normal orders or visitors a day, your busiest hour last year, and anything that slowed down, failed or oversold. Rough numbers are fine.
Pick what you are getting ready for
A peak or big sale, steady growth, a replatform, site speed or running costs. The same setup can be fine for one and fragile for another.
Start with what breaks first
Bottlenecks are grouped into fix before your busy period, plan for next quarter, and not urgent. Each one says what you would see when it fails, why, the fix and a first step for this week.
Answer the open questions and test
The Open questions tab lists what the tool could not tell from your description, and the What to test tab gives you load test scenarios. Download the review as a PDF or Markdown for your developers.
What ecommerce architecture actually covers
Every online shop has the same layers, whether it runs on Shopify, Magento, WooCommerce or something custom. The names change. The jobs do not.
When I review a shop, I map it onto these first, because it shows straight away where the risk sits and who owns it:
- Storefront. The pages shoppers see: a theme, a headless front end in Next.js, or templates on the server. This is where site speed lives.
- Platform. Shopify, Magento (Adobe Commerce), WooCommerce, BigCommerce, Salesforce Commerce Cloud, commercetools, or your own. It holds products, baskets, customers and orders.
- Checkout and payments. The path from basket to paid order, plus Stripe, Adyen, PayPal, Klarna or whoever takes the money. The most valuable minute of the whole journey.
- Search and catalogue. Site search, filters, product data, a PIM if you have one. Slow search on a big catalogue quietly kills sales.
- Data. The database and any caching in front of it. On a hosted platform you never see it. Self-hosted, it is usually the first thing to struggle.
- Integrations. Stock and ERP sync, order export to the warehouse, email, reviews, loyalty, marketplaces. This is where most of the surprises are.
- Infrastructure and operations. Hosting, the CDN, monitoring, alerts, deployments, and the person who gets the call when it breaks.
Where ecommerce sites break under load
Eliyahu Goldratt's Theory of Constraints, from his 1984 book The Goal, says a system only moves as fast as its tightest bottleneck. Speeding up anything else is wasted effort. That is exactly how a shop behaves on Black Friday. It does not slow down evenly. One thing gives, and everything behind it queues.
In my experience, it is rarely the platform core. Hosted platforms scale that part for you, and a self-hosted one usually fails in a few predictable places. These are the ones I check first:
- Stock sync on a timer. A cron job that pushes stock from the ERP every 15 minutes is fine on a Tuesday. During a product drop it means 15 minutes of selling things you no longer have.
- Checkout doing too much. Every extension that hooks into checkout (fraud checks, loyalty points, address lookup, tax) adds a call that can be slow or fail, and they run on the busiest page of the busiest day.
- The database sharing a box with everything else. One server running the web app, the database and search is the classic self-hosted setup, and it runs out of room all at once.
- Pages that are not cached. Category pages, search results and anything personalised can skip the cache and land on the database every time.
- Third-party scripts. Chat widgets, tag managers, review badges and pixels slow every page down for every shopper, and none of them are in your hosting bill.
- Order export. The warehouse or ERP integration that cannot keep up, so orders arrive late, twice or not at all. Shoppers do not see it on the day. Your customer service team sees it on Monday.
- App and API limits. On hosted platforms, apps and integrations share API rate limits, and a busy sync can starve everything else.
Ecommerce scalability vs performance
They get used as if they mean the same thing. They do not, and mixing them up is how teams spend a month on the wrong problem.
Performance is how fast a page is for one shopper. Google measures that as Core Web Vitals: Largest Contentful Paint (how quickly the main content appears, good is 2.5 seconds or less), Interaction to Next Paint (how quickly the page responds to a tap, good is 200 milliseconds or less) and Cumulative Layout Shift (how much things jump around, good is 0.1 or less). Heavy themes, big images and third-party scripts are the usual culprits.
Scalability is whether it stays that fast when a thousand shoppers turn up at once. Little's Law is the useful bit of maths here: the number of requests in flight equals the arrival rate multiplied by how long each one takes. So a checkout call that slows from half a second to five seconds under load means ten times as many requests piling up, which is how a slow page turns into a down site.
A fast shop can still fall over on Black Friday, and a shop that never goes down can still be slow. The tool asks what you are getting ready for, so it can weigh the two properly.
Do you need to replatform or go headless?
Sometimes. Less often than the agency pitching it will tell you.
Before you move, check whether the problems you have are caused by the platform at all. Slow pages from a bloated theme and 20 apps will follow you to a new platform if you reinstall the same 20 apps. A stock sync that oversells will oversell from anywhere. Moving platforms fixes platform problems: hitting real limits of your plan, a version that is out of support, a data model that cannot represent how you sell.
Headless (a separate front end talking to the platform through its API) buys you a faster, more flexible storefront. It also gives you a second system to host, monitor and pay people to maintain. For a big catalogue with a strong in-house team it can be the right call. For a small team, it often adds more moving parts than it removes.
Pick "A replatform or headless move" in the tool and it will tell you which of your problems a move would solve, and which would come with you.
An ecommerce scalability checklist before Black Friday
If your busy period is a few weeks away, this is the order I would do things in. It is short on purpose. The week before a peak is the worst time to start a big change.
- Freeze risky changes. Agree a date after which nothing new ships unless it fixes something on this list.
- Load test the path to a paid order at a multiple of last year's busiest hour, on a staging copy where you can. Check your platform's rules on load testing first.
- Put alerts on what costs money: payment failures, checkout errors, orders not reaching the warehouse, stock going negative.
- Move stock updates from a timer to events where your ERP allows it, or at least shorten the timer for the peak.
- Strip third-party scripts you do not need on product and checkout pages.
- Write down who is on call, how to roll back, and how to switch off a misbehaving app or integration in a hurry.
What this tool cannot tell you
It works from what you type. It cannot see your code, your hosting, your database or your traffic graphs, and it has not load tested anything. If you describe a server as "big" or an integration as "fine", it has to take your word for it. Teams misjudge their own systems in both directions all the time. The thing everyone worries about holds up, and the thing nobody mentioned falls over.
It will not give you prices, hosting costs, savings or effort in days, and it does not know the current plan limits of any platform. Any number it produced from a description would be made up.
It is also a language model, so read the findings as a well-argued list of where to look first. The Open questions tab shows where it had to guess. Answer those first, and check every finding against the real system before you spend money on it.
Before your first result we ask for your name, work email and company. What you put into that first run travels with those details to our CRM, inbox and team chat, so a person can read it and reply. After that, what you type goes to the model. We keep each result, which can quote what you put in: it is emailed to you as a PDF and saved in our CRM. Either way, leave out passwords, API keys, server addresses and customer data. Describe the setup, not the credentials.
Frequently asked questions
It is how the parts of an online shop fit together: the storefront, the ecommerce platform, checkout and payments, search, the database, integrations such as stock, ERP and email, and the hosting and monitoring under them. Monolithic platforms such as Magento or WooCommerce keep most of that in one application. Hosted platforms such as Shopify run the core for you. Headless and composable setups split the storefront and other parts into separate services that talk over APIs.
Find the tightest bottleneck on the path from product page to paid order and fix that first, then test again. In practice that usually means caching pages that do not need to be built for every visit, moving the database off the web server on self-hosted setups, replacing timed stock syncs with event-driven ones, cutting the number of extensions in checkout, and load testing at a multiple of your last peak before the next one.
Performance is how fast the shop is for one shopper, which Google measures with Core Web Vitals. Scalability is whether it stays that fast, and stays up, when many shoppers arrive at once. You can have either without the other, so it matters which one you are fixing.
Only if your current storefront is the thing holding you back and you have the team to run a second system. Headless gives you a faster, more flexible front end, and also a separate application to host, monitor and maintain. Many problems blamed on the platform are caused by apps, themes or integrations, and a headless move does not fix those.
Freeze risky changes a few weeks out, load test checkout and the order pipeline at a multiple of last year's busiest hour, put alerts on payment failures and stuck orders, tighten stock syncing, remove scripts you do not need, and write down who is on call and how to roll back. The tool turns that into a list specific to your setup.
Shopify runs and scales the platform itself, so you do not manage servers or the database. What it does not scale for you is everything you add: theme weight, apps, third-party scripts, and integrations that share API rate limits. On Shopify those are where peak problems usually come from.
Yes. You get three runs. Before the first result we ask for your name, work email and company, and for you to accept the terms, and that is the whole price. There is no paid tier.
No. It reviews the setup you describe and tells you what to test and where to look. To test the real thing you need a load testing tool such as k6, Gatling or JMeter run against a staging copy, and someone who knows the system to read the results.
Related from Metamindz
- Fractional CTOA senior CTO who reads the real system, runs the load tests and owns the fix list until the busy period is over.
- Technical due diligenceAn independent assessment of your codebase, hosting and team, for when you need a written verdict rather than a first pass.
- Software and app developmentFor when the fix list is longer than your team.
- EcommerceHow we work with online retailers and ecommerce teams.
- Building scalable ecommerce architectureThe longer read on the patterns behind a shop that scales.
- All free tools
Also known as: Ecommerce Architecture Design, Ecommerce Scalability.
Published