Home / Services / Commerce Backend and API

Commerce Backend and API

Commerce backend and API engineering: catalogue, pricing, cart, checkout and order services with idempotent writes, versioned contracts and capacity proven by load test.

Backend

Services that behave correctly when things go wrong

Any backend works on a good day. Ours are designed for the bad ones: a timeout mid checkout, a duplicate webhook, a warehouse that stops answering, a marketing email that triples traffic in ninety seconds.

  • Idempotency keys on every state changing call, so a retry can never charge or ship twice
  • Explicit order state machine with every transition logged and replayable
  • Circuit breakers and cached fallbacks around every external dependency
  • Versioned API contracts with consumer driven contract tests in the pipeline
  • Capacity proven by load test against three times the historic peak hour
Data centre server racks running eCommerce backend services

Write path

Placing an order, exactly once

Order placement sequence with strong customer authentication

Figure 06 / sequence
Storefront Checkout service Payment orchestrator Order service Event bus and ERP POST /checkout with Idempotency-Key create payment intent, amount locked action required, 3DS challenge challenge completed by the shopper, exemption evaluated authorised, reference stored create order, same idempotency key, stock reserved OrderCreated published, at least once ERP acknowledges, or the message is retried 201 Created, order reference returned to the shopper If the shopper refreshes, the browser crashes or the network drops at any point, the same idempotency key returns the same order rather than creating a second one. If the ERP is unavailable, the order is still accepted. The event stays on the bus, is retried with backoff, and lands in a dead letter queue with an alert if it keeps failing.
Command Response or event acknowledgement

Figure 06. Every commerce backend we build is designed around this path first. Everything else is easier than taking money correctly.

Service level objectives

The numbers we design to

These are the defaults. They are adjusted to your traffic profile during discovery and then written into the statement of work as acceptance criteria.

CapabilityLatency target, p95AvailabilityProven by
Catalogue read60 ms at the API, 12 ms at the edge99.99%Load test at 3x peak, synthetic checks per deploy
Price and promotion calculation90 ms99.99%Load test with the real rule set, not a sample
Add to cart120 ms99.98%Load test plus chaos test on the stock dependency
Checkout submit450 ms excluding the payment provider99.98%Load test plus provider timeout simulation
Order write250 ms99.98%Idempotency test suite, duplicate delivery test
Stock synchronisationUnder 60 seconds end to end99.9%Reconciliation report against the ERP, run daily

Table 04. Availability excludes planned maintenance windows agreed in advance, which we schedule outside your trading peak.

Next step

Tell us what is slowing your commerce platform down

Send the brief. A principal architect reads it, then you get a written technical assessment with options, effort and risk inside five working days. No sales call required first.