All blueprints
E-commercecomplex complexity

E-commerce Platform Architecture

Scalable e-commerce architecture with product catalog, cart, checkout, order management, and inventory that survives flash sales without melting.

7

Components

5

Considerations

3

Alternatives

complex

Complexity

Fit

When this blueprint fits

And when to walk away from it

When to use this

You need a custom storefront where merchandising, checkout flow, and post-purchase experience are competitive differentiators. This is the right starting point if Shopify Plus is too restrictive but you do not want to reinvent everything from cart to fulfillment.

When NOT to use this

If your catalog is under 1,000 SKUs, your team is under five people, and your differentiation is product not platform, just use Shopify. The total cost of ownership on a custom build is rarely justified below that threshold.

Architecture

System components

Key building blocks of this architecture, layered from infrastructure up.

01

Product Catalog

Flexible product modelling with variants, attributes, categories, bundles, and pricing rules. The biggest mistake I see is teams modelling products as flat tables and then bolting on attributes when buyers ask for size and color filters. Start with a product-variant-option model from day one, even if you only ship two product types. Indexed in PostgreSQL for the source of truth, mirrored into a search index for query performance. Powers many builds in e-commerce.
PostgreSQLAlgoliaMeilisearchCDN
02

Shopping Cart

Persistent cart with guest and authenticated user support, served by Redis with PostgreSQL as the durable backup. Carts should survive device switches, sign-in flows, and 24-hour sessions. I keep the cart as a server-side resource keyed by an HTTP-only cookie, never trust client state for pricing, and recompute totals on every render so promo logic stays consistent.
RedisServer ActionsHTTP-only Cookies
03

Checkout Flow

Multi-step checkout with address validation, tax calculation, shipping options, and payment. I prefer a single-page checkout backed by a state machine so I can resume from any step. Hosted payment fields are non-negotiable for PCI scope reduction. See Stripe vs Adyen for provider choice, and the payment pipeline blueprint for the deeper architecture.
Stripe ElementsTaxJarAddress Validation
04

Order Management

An explicit order state machine with statuses for pending, paid, fulfilled, shipped, delivered, refunded, and disputed. Every transition emits a domain event so downstream systems (warehouse, accounting, email, analytics) can react without coupling to the core order service. The audit trail this produces is also your customer support tool.
XStateWebhooksDomain EventsEmail
05

Inventory System

Real-time inventory tracking with reservation, allocation, and fulfillment. Reserving stock during checkout is the single hardest correctness problem in e-commerce. I use database-level locking with a short reservation TTL, and event-sourced inventory movements so I can replay history during reconciliation. Use the event-driven systems playbook.
PostgreSQLRedis LocksQueueWebhooks
06

Promotions Engine

Rules for discounts, coupons, gift cards, and bundles. Even simple stores end up wanting buy-X-get-Y-at-Z%-off-but-not-with-this-other-promo by year two. Build a small rules DSL early, version your promotions, and log every applied rule on the order line item so finance can audit margin.
Custom DSLPostgreSQLFeature Flags
07

Search and Merchandising

Faceted search, autocomplete, synonyms, and merchandiser-controlled ranking rules. Search is the highest-converting surface after the homepage. Algolia or Meilisearch handle the heavy lifting, but you still own the index pipeline, query analytics, and zero-result rescue logic.
AlgoliaMeilisearchSynonyms

Planning

Critical considerations

The things I have learned the hard way and would not skip on the next build.

Inventory reservation during checkout is the failure mode that ends quarters. Use database transactions with row-level locks, set a short TTL on reservations, and run a reconciliation job every minute to release abandoned ones.
Plan for sale-day traffic with the edge caching playbook. Product pages, category pages, and the homepage should serve from the edge with stale-while-revalidate. Only the cart, checkout, and account areas need to bypass cache.
International from day one is cheaper than international as a year-two project. Build with multi-currency pricing, locale-aware tax, and address formats from the schema up.
Build the merchandising and admin tools before you launch. Marketing and ops will need to change prices, run promotions, and adjust inventory daily. A merchant unable to self-serve is a future support ticket.
Wire your analytics and event tracking before you write your first checkout test. The data you do not capture in week one is the data you cannot analyse in month six. Contact me for an architecture review.

Options

Alternative approaches

Where I would consider a different shape entirely, with the trade-offs spelled out.

Alternative 01
Shopify Plus for faster time-to-market with managed infrastructure. The right call for 80% of stores under £20M GMV.
Alternative 02
Medusa or Vendure for open-source headless commerce when you want full control without rebuilding the cart and order primitives.
Alternative 03
Commerce Layer or Saleor for API-first commerce when you have a custom front-end team but want managed commerce primitives.
Need a partner on this?

Need help implementing this blueprint?

I help teams adapt blueprints like this to their specific requirements and ship from planning through production.