Scalable E-commerce Architecture: What to Build, What to Buy and How to Survive Peak
Last updated: 14 October 2026
A scalable e-commerce architecture is one that handles more traffic, more products, more orders and more developers without a rebuild, and without costs growing faster than revenue. For most online shops that means a proven platform (SaaS or a well-built monolith), aggressive caching and a CDN, a database tuned for reads, queues for everything that happens after checkout, and load testing before every peak. Microservices come later, if at all.
I've reviewed a lot of e-commerce platforms as a CTO and in technical due diligence. The ones that fall over on Black Friday rarely picked the "wrong" architecture. They skipped the boring parts: nobody load-tested checkout, the database was doing work a cache should have done, and one slow third-party call took the whole basket down with it.
- What "scalable" actually means for e-commerce
- Monolith vs headless vs composable vs microservices
- The building blocks that carry the load
- A peak-traffic checklist
- What to monitor
- Choosing a platform
- FAQ
What "scalable" actually means for e-commerce
Scalability gets used as if it only means "doesn't crash under load". For an online business it has four parts:
- Traffic: peak days can bring many times your normal load in a few minutes. At its Black Friday peak in 2025, Shopify's merchants were selling $5.1 million per minute, and Shopify was processing 11TB of logs per minute to keep it running.
- Catalogue and data: more products, variants, prices, markets and order history without search and category pages getting slower.
- Team: more developers shipping changes without stepping on each other.
- Cost: infrastructure and licence costs that grow slower than revenue.
Speed belongs in this list too, because it's revenue. In a study of 37 brand sites and over 30 million sessions, a 0.1 second improvement in mobile site speed was associated with an 8.4% increase in retail conversions and a 9.2% increase in average order value (Deloitte with Google, "Milliseconds Make Millions", 2020).
Monolith vs headless vs composable vs microservices
This is the decision people agonise over most. Here's how I'd compare the main options:
| Architecture | What it is | Scales well when | Watch out for |
|---|---|---|---|
| SaaS platform (e.g. Shopify, BigCommerce) | The platform runs the whole stack; you configure and extend it | You want the vendor to own uptime and peak traffic | Limits on custom checkout logic, B2B pricing and data ownership; app sprawl |
| Monolith (self-hosted, e.g. Adobe Commerce, a custom app) | One codebase and one database for storefront, catalogue and orders | One team, one main market, a sensible caching layer | Every deploy touches everything; scaling means scaling the whole app |
| Modular monolith | One deployable app, split internally into clear modules (catalogue, pricing, orders) | You expect growth but don't want distributed-systems overhead yet | Needs discipline to keep the module boundaries clean |
| Headless | A separate frontend (e.g. Next.js) talking to the commerce backend by API | Content and brand experience matter, and you have frontend developers | Two systems to run; you now own frontend performance and caching |
| Composable / MACH (e.g. commercetools) | Best-of-breed services for search, CMS, cart, payments, joined by APIs | Several markets, brands or channels, and a platform team to own the joins | Integration cost, many vendors, many contracts |
| Microservices | Your own independently deployed services, each with its own data | Several teams need to deploy independently, and load differs a lot between parts of the system | Distributed failures, observability cost, data consistency between services |
My view: most shops under a few hundred orders a minute at peak don't need microservices. Splitting one database into ten services gives you ten things to monitor and a pile of new ways to fail, and it doesn't make checkout faster. Start with a SaaS platform or a modular monolith, cache hard, and only split out the part that's genuinely under different load (search and the order pipeline are the usual candidates). If you're considering going headless with an agency, read 9 questions to ask a headless e-commerce agency before you sign first.
The building blocks that carry the load
1. A CDN and edge caching
Product images, scripts and styles, and as much of category and product pages as possible, should come from a CDN such as Cloudflare or Fastly. Every request the CDN answers is one your servers never see. Cache whole pages for anonymous users and personalise the small bits (basket count, prices for logged-in B2B customers) on the client or at the edge.
2. An application cache
Use Redis or Memcached for anything read often and changed rarely: product data, category trees, prices, stock levels with a short expiry. Decide up front how each cache gets invalidated, because "the price changed but the site still shows the old one" is a support ticket you'll get on your busiest day.
3. A database built for reads
Shops read far more than they write: thousands of product views for every order. So:
- Keep orders, payments, customers and stock in a relational database (PostgreSQL or MySQL). You need transactions there.
- Index what you filter and sort by, and check the slow query log before every peak.
- Add read replicas for catalogue and search traffic, so browsing never competes with checkout.
- Move search and faceted filtering to a search engine (Elasticsearch, OpenSearch, Algolia or similar) instead of building it in SQL.
4. Queues for everything after "Place order"
Checkout should do the minimum: take payment, reserve stock, write the order. Confirmation emails, ERP and warehouse updates, loyalty points and analytics go onto a queue (SQS, RabbitMQ, Kafka or your platform's webhooks) and are processed in the background. This is the event-driven part, and it's the single change that most often stops peak traffic from taking checkout down.
5. Timeouts and fallbacks on every third party
Payment providers, tax calculators, address lookups, recommendation widgets, reviews. Each one needs a timeout and a plan for when it's slow. A recommendations widget that hangs should disappear from the page. It should never block the basket.
6. Autoscaling with a ceiling
If you run your own infrastructure (containers on Kubernetes, ECS or similar), scale the stateless app tier automatically, set a maximum, and remember the database doesn't autoscale the same way. Scaling app servers in front of a saturated database just makes the queue longer.
A peak-traffic checklist
Start six to eight weeks before Black Friday or a big launch:
- Load test the real journeys (browse, search, add to basket, checkout) with k6 or JMeter, at well above your expected peak. Test against production-like data, not an empty database.
- Find the first thing that breaks and fix it. Then test again, because the bottleneck moves.
- Check every third-party limit: payment provider rate limits, email provider quotas, ERP API limits.
- Put non-essential features behind feature flags so you can switch off recommendations, reviews or live chat under load.
- Have a queue page ready for extreme spikes. A waiting room beats an error page.
- Freeze code for the peak period, with a rollback plan for anything that has to ship.
- Agree who's on call, with dashboards and alerts already set up, and a runbook for the obvious failures.
What to monitor
Track the things that tell you customers are buying, not just that servers are up:
| Metric | Why it matters |
|---|---|
| Checkout success rate | The number that is your revenue. Alert on drops, not just errors. |
| p95 page and API response time | Averages hide the slow requests your customers actually feel. |
| Error rate by endpoint | Tells you which part of the journey is failing. |
| Payment provider response time and decline rate | A slow or failing provider looks like your site is broken. |
| Queue depth and age | A growing backlog means orders aren't reaching the warehouse. |
| Database CPU, connections and slow queries | Usually the first real limit you'll hit. |
| CDN cache hit ratio | A drop means more traffic is reaching your servers than you planned for. |
Datadog, New Relic, Grafana with Prometheus, or your cloud provider's own tooling will all do the job. The tool matters less than having the dashboards and alerts set up before the peak, not during it.
Choosing a platform
The honest order of questions:
- How custom is your business logic? Standard D2C retail fits a SaaS platform well. Complex B2B pricing, configurators or marketplace logic push you towards headless or composable.
- How many markets, brands and channels? One storefront in one market rarely justifies composable.
- Who will own it? Every step from SaaS towards microservices needs a stronger in-house or partner engineering team. Without that, the architecture becomes a liability.
- What does the total cost look like over three years, including licences, apps, hosting, agency retainers and the team?
If you already have a platform and want to know whether it'll survive your next stage of growth, our free e-commerce architecture review will give you a straight read on it. For a deeper look, a fractional CTO can review the architecture, run the load tests with your team and plan what to change before peak.
Frequently asked questions
What is e-commerce scalability?
E-commerce scalability is a platform's ability to handle more traffic, products, orders, markets and developers without slowing down, breaking, or needing a rebuild, while keeping costs in proportion to revenue.
How do you build a scalable e-commerce platform?
Start with a proven platform or a modular monolith, put a CDN and caching in front of it, keep transactional data in a relational database with read replicas, move post-checkout work onto queues, put timeouts on every third party, and load test before every peak.
Do I need microservices to scale an online shop?
Usually not. Microservices help when several teams need to deploy independently or one part of the system has very different load. For most shops, caching, read replicas and queues solve the scaling problem at a fraction of the complexity.
What is the best e-commerce architecture for global scaling?
For several countries, a CDN with edge caching close to customers matters most. Add multi-currency and multi-language support in the platform, and consider headless or composable only when markets need genuinely different experiences, catalogues or integrations.
How do I prepare an e-commerce site for Black Friday traffic?
Load test the full journey well above your expected peak, fix the first bottleneck and test again, check third-party limits, put non-essential features behind flags, prepare a queue page, freeze code and have people on call with dashboards ready.