E-Commerce Engineering: Shopify Custom Apps & Scalable WooCommerce Systems

The engineering question is never “which platform is better”. It is which set of constraints you would rather work inside, because both trade the same things against each other in opposite directions.

Where the two platforms actually differ

Shopify’s constraints are visible on day one. WooCommerce’s arrive at volume, which is later and more expensive.

WooCommerce at scale: the specific bottlenecks

WooCommerce is built on WordPress’s post and meta tables, and that inheritance is where the problems originate.

Product queries over a large catalogue

Filtering products by attribute means querying meta – and meta queries across a large table without appropriate indexing degrade sharply. Modern WooCommerce provides lookup tables for exactly this reason; use them rather than querying meta directly. Beyond a certain catalogue size, a dedicated search index is not an optimisation but a requirement.

Orders in the posts table

Historically every order was a post with dozens of meta rows, which put transactional writes and content reads in contention on the same tables. High-performance order storage moves orders into their own schema and is the single largest structural improvement available to a busy store. Migrate to it.

Cart and session under load

Carts are per-user and uncacheable, so every cart interaction is a full application request. Sessions in the database become a write bottleneck during a sale; move them to Redis. And exclude cart, checkout and account pages from page caching properly – a cached cart page served to the wrong customer is the worst bug in commerce, and it is entirely preventable.

Stock and race conditions

Two customers buying the last unit simultaneously is a concurrency problem, and read-then-write stock logic will oversell under load. Stock decrements need to be atomic at the database level. This is exactly the scenario that only appears during the promotion you built the feature for.

Extending checkout without forking it

The most damaging decision available in either platform is modifying checkout in a way that cannot be upgraded.

On WooCommerce, use the documented hooks and the Store API rather than overriding templates wholesale. An overridden checkout template is a fork: it stops receiving upstream security fixes, and every core release becomes a manual merge. When a change genuinely cannot be expressed through hooks, the honest options are to contribute the hook upstream or to reconsider the requirement.

On Shopify, checkout extensibility is deliberately bounded. Work within the extension points provided; anything that requires replacing checkout entirely is a signal that the requirement and the platform are mismatched, and discovering that early is worth a great deal.

Custom Shopify apps: the parts that bite

• Rate limits are a design input. Shopify’s APIs are cost-based rather than request-based – a deeply nested GraphQL query consumes far more budget than a simple one. Batch with bulk operations for large jobs, and implement backoff that respects the returned cost headers rather than guessing.
• Webhooks are at-least-once. Same rules as any webhook pipeline: verify the signature against the raw body, deduplicate on the delivery id, acknowledge fast and process asynchronously. The full treatment is in Designing Resilient Multi-Platform Data Pipelines with n8n and Webhooks.
• Metafields are the data model. Define them deliberately with types and validation rather than accumulating them ad hoc. They are the schema for everything the platform does not model natively.
• Storefront performance is still yours. A custom theme can be as slow as any other front end. Theme scripts and app embeds are the usual cause.

Inventory synchronisation between systems

Any store selling through more than one channel eventually has an inventory consistency problem. What makes it tractable:

• One system is authoritative. Decide which, and make every other system a replica. Bidirectional sync without a designated source of truth produces conflicts that cannot be resolved automatically because there is no correct answer.
• Sync deltas, not snapshots. Full catalogue syncs are slow, expensive in API budget, and hide the moment something diverged.
• Reconcile on a schedule regardless. Events get dropped. A nightly comparison against the authoritative system catches what the event pipeline missed, and the count of discrepancies it finds is a health metric worth alerting on.
• Hold a buffer on shared stock. If the same physical inventory is sold through several channels, propagation delay will oversell it. A small reserve is cheaper than cancelling orders.

Load: the traffic pattern that matters is the spike

Average traffic is not the design constraint. A flash sale or a campaign send produces a step change in concurrent checkouts, and checkout is the part of the system that cannot be cached, cannot be made eventually consistent, and is where the money is.

Load-test the checkout path specifically, with realistic concurrency, before the campaign rather than during it. Test the failure behaviour too: what a customer sees when the payment gateway times out is a product decision, and if nobody has made it, the answer will be a stack trace.

The caching and query-budget work underneath all of this is the same discipline described in Full-Stack Web Performance.

Questions people actually ask

Shopify or WooCommerce?

Shopify when you want the platform to own checkout, scaling and PCI scope, and your requirements fit inside its extension points. WooCommerce when you need control over the data model, checkout logic or hosting, and you have the engineering capacity to own performance and security. The deciding question is usually whether any requirement is impossible on Shopify – if none is, the operational saving is substantial.

Why does WooCommerce slow down as the catalogue grows?

Product filtering resolves to meta queries over tables that grow with every product and every attribute, and those degrade non-linearly. Enable WooCommerce’s product lookup tables rather than querying meta directly, move orders to high-performance order storage, and add a dedicated search index once the catalogue is large enough that filtering is the slow path.

How do I stop overselling during a flash sale?

Make stock decrements atomic at the database level rather than reading stock, deciding, and then writing. Read-then-write logic has a race window that only opens under concurrency, which is precisely the condition a flash sale creates. If inventory is shared across channels, also hold a buffer to absorb propagation delay.

Can I customise Shopify checkout?

Within the extension points Shopify provides, yes – and those have broadened considerably. What you cannot do is replace it. If a requirement genuinely demands replacing checkout, that is a platform-fit signal worth taking seriously early, because the workarounds tend to be fragile and expensive to maintain.

What is the safe way to customise WooCommerce checkout?

Hooks and the Store API, never a wholesale template override. An overridden checkout template is a fork of code that receives security fixes, so every core release becomes a manual merge and a chance to reintroduce a vulnerability. If the change cannot be expressed through a hook, propose the hook upstream rather than forking around it.