E-commerce architecture: connecting catalog, orders, payments and logistics

A ready platform works when catalog, pricing, order and delivery fit its rules. Custom backend is justified when unique pricing, partner roles, logistics or integrations are a competitive advantage.

Do not rebuild everything for control. Identify the part that actually limits margin, speed or customer experience.

Catalog may live in ERP, inventory in WMS, prices in a pricing service and orders in the commerce system. Each object needs an owner and synchronization rules.

Otherwise storefront, warehouse and operator will show different truths. That becomes cancellations, refunds and manual work.

Created, reserved, paid, picked, shipped, completed and returned are states with rules and side effects, not labels.

Payment events can repeat, warehouses can be slow and users can close the page. The system must retry safely and avoid double charges.

If the business promises availability and delivery dates, inventory and fulfillment cannot be deferred indefinitely. Even an MVP needs a clear reservation and shortage path.

Start with one complete catalog-to-delivery journey instead of many connections without cancellation and reconciliation rules.

Payment, CRM, warehouse and delivery providers can be unavailable. Use retries, event logs, operator alerts and a visible manual-review state.

Logs should show where an order stopped without exposing secrets or unnecessary personal data.

Track time from order to payment, stock-related cancellations, integration errors, manual interventions and returns. These show where the platform loses money and trust.

Growth can then add payments, warehouse paths, mobile, loyalty and B2B pricing based on evidence.

Decide where product, price, availability and order status are authoritative. If catalog, stock and discounts live in separate systems, document sync rules and update delay.

Create explicit product and order states: draft, published, reserved, paid, packed, shipped and returned. Mixing states causes wrong prices, duplicate charges and manual fixes.

A payment can fail, settle later or be partially refunded. Fulfilment can split an order, change its cost or return a parcel. These events must be idempotent and visible to operators.

Keep an event log and a reconciliation job that compares internal records with providers. This exposes discrepancies before a customer reports them.

Traffic peaks at search, cart, shipping quotes, promotions and checkout, not only the homepage. Cache safe reads and protect stock and payment operations with transactions and rechecks.

Monitor funnel signals: search errors, abandoned carts, failed payments, webhook delay and queue age. These connect technical degradation to lost orders.

Catalog data changes through editors and suppliers, while an order must preserve the price, items and terms accepted at purchase time. Mixing the models lets a product edit rewrite order history accidentally.

Model separate states for cart, reservation, payment, fulfilment and return. A customer sees one order, but internally it is a chain of operations with different owners and confirmation times.

Payment, warehouse, delivery and notification providers have different latency and failure modes. Store their IDs and statuses so a retry cannot create a duplicate. A provider error must not erase local history.

Use idempotent commands and an event log for critical transitions. This lets the team recover after a timeout and tell an operator exactly where the chain stopped.

Performance matters during normal operations too: managers need fast price edits, support needs order search and buyers need a safe payment retry. Measure critical queries against realistic catalog volume.

Before scaling traffic, test caching, search, background queues and provider limits. Horizontal application scaling will not help if inventory or warehouse APIs remain the bottleneck.

Orders move through reservation, payment, picking, delivery, return and cancellation. Define the event source, safe retries and manual authority for each transition.

This lifecycle protects inventory and money from races between storefront, warehouse and payment provider. A simple paid/unpaid flag fails on partial refunds and split shipments.

Descriptions can tolerate delay; stock needs freshness and reservation rules. Separate those data contracts so a stale catalog does not look like available inventory.

Test multiple warehouses, substitutions and partial fulfillment before selecting a cache. Caching speeds reads but does not define the source of truth.