E-Commerce App Development

Companies building e-commerce applications are competing on milliseconds and margin. A checkout that is 100ms slower costs measurable conversion. A product catalogue that cannot handle a flash sale at 50x baseline traffic costs revenue. Scrums.com engineers dedicated teams for retail brands, marketplace operators, and commerce-enabled SaaS platforms that are building or rebuilding their e-commerce infrastructure, not using Shopify but building the systems that compete with it.

Product Catalogue and Search Architecture

The product catalogue is the most queried data in any e-commerce system and the most expensive to get wrong. A normalised relational schema works for order management but creates fan-out join problems at product listing scale. The performant pattern separates catalogue storage from catalogue serving: PostgreSQL or a PIM system as the source of truth for product data, with a search index (Elasticsearch or OpenSearch) as the read model for browsing, filtering, and full-text search.

Product attributes are modelled as a flexible schema with a typed attribute registry, not a flat product table with 200 nullable columns. This allows different product categories (electronics with voltage specs, clothing with size/colour variants, furniture with dimensions) to share the same storage layer without schema migrations for each new attribute type.

Variant modelling uses a product / variant hierarchy: the product defines shared attributes (brand, category, description) and the variant defines purchasable options (SKU, price, stock level, images). This ensures that a product with 50 colour-size combinations is represented correctly without duplicating shared content.

Search relevance requires more than keyword matching. A merchandising layer allows the catalogue team to boost products by margin, newness, or commercial priority without code deployments: implemented as scoring function parameters in the Elasticsearch query DSL, stored as configuration in the admin system. Synonyms, spell-correction, and faceted navigation (size, price band, brand) are configured in the index rather than application code.

Cart, Checkout, and Payment Architecture

The cart is the highest-stakes component in an e-commerce system. A lost cart is lost revenue that cannot be recovered.

Cart state lives in Redis with a TTL of 30 days, backed by PostgreSQL for persistence on session expiry. Every cart modification is an append to a cart_events log (item_added, item_removed, quantity_changed, coupon_applied); the current cart state is a projection over this log. This means abandoned cart recovery, analytics, and A/B testing on cart behaviour all operate against a complete event history rather than a snapshot.

Stock reservation during checkout uses a two-phase pattern: a soft reservation (Redis decrement with TTL) is created when the user enters checkout, and a hard allocation is committed to the inventory_reservations table on payment capture. The reservation TTL (typically 15 minutes) prevents stock from being locked indefinitely by users who abandon checkout. If the reservation expires before payment is captured, the soft hold is released and the user receives a stock availability warning rather than a silent checkout failure.

Payment processing delegates card handling entirely to a PCI-compliant vault (Stripe, Adyen, Braintree); raw card data never touches the platform's servers. The platform receives a payment method token and initiates a charge via the provider's API. The payment result is written to a payment_events append-only log (initiated, authorised, captured, refunded, disputed), never as a status field on the order record. This means the full payment history is auditable and refund/dispute events cannot overwrite prior states.

E-commerce platforms like these are built end to end through our mobile app development service.

Order Management and Fulfilment Architecture

Once payment is captured, the order enters a lifecycle managed by a configurable state machine. Order states (placed, confirmed, picking, shipped, delivered, returned, cancelled) are transitions, not field updates; each transition is logged in an order_events table with the actor (system, customer, operator), timestamp, and metadata. This design makes the order timeline a first-class feature rather than a derived log.

Multi-location fulfilment routes orders to the warehouse or store closest to the delivery address using a routing policy table (configurable by category, inventory level, and carrier SLAs), not hardcoded logic. Routing policy changes are configuration deployments that take effect on the next order without code deployments or downtime.

Split shipment is modelled at the line-item level, not the order level. An order containing both in-stock and pre-order items creates two fulfilment lines with independent state machines. The customer-facing order summary projects a single view from the two lines; the warehouse system sees only the lines assigned to it.

Returns and cancellations reverse inventory at inspection completion (not at return request) to prevent phantom stock. A return creates a return_request entity linked to the original order line; the inventory reversal event is only emitted when the physical item passes inspection and is marked restockable. Non-restockable items emit a writeoff event instead.

Personalisation, Promotions, and Commerce Analytics

Personalisation in e-commerce operates at three latency tiers. Real-time personalisation (product recommendations on the product page, cart upsells) requires sub-100ms inference: served from a pre-computed recommendation cache (Redis) keyed by user_id and context (current product, cart contents). The recommendation models are trained offline (collaborative filtering, content-based) and the cache is refreshed on a cadence, not on-demand per request.

Session-level personalisation (homepage layout, category ranking) uses the current session's browse signal accumulated in the request context; no ML inference required. Rules-based sorting (most-viewed in session first, recently-viewed category promoted) implemented in the merchandising layer covers most of the value without model infrastructure.

Promotions are defined as configuration, not code. A promotion record specifies the trigger (cart value, SKU set, user segment, date range), the discount type (percentage, fixed, free shipping, BOGO), the stacking policy (exclusive, stackable, priority order), and the usage limits (per-user, global). The promotion engine evaluates applicable promotions at cart calculation time using the configuration: adding a new promotion type requires a configuration change, not a code deployment.

Commerce analytics distinguishes between operational metrics (orders per hour, fulfilment SLA compliance) served from ClickHouse for real-time visibility, and strategic metrics (customer lifetime value, cohort repeat purchase rate, attribution by channel) computed in dbt against the warehouse. Revenue figures always use the payment capture timestamp, not the order placed timestamp, to match financial reporting conventions.

For FinTech-adjacent commerce platforms, explore Scrums.com's FinTech engineering capabilities or start a conversation today.