E-COMMERCE DEMONSTRATION

E-commerce architecture: keep orders consistent during change

Repeated events, competing reservations and a data conversion expose three ways an order flow can become inconsistent.

An independent demonstration using synthetic customers, orders and payment events. The findings were reproduced in a controlled model; this is not a client engagement or an audit of a live store.

The business question

Will an order stay correct when messages repeat, customers compete for stock or data moves to a new system?

The in-memory model uses a deterministic interleaving of two stock requests, repeated order events and three legacy order records. It demonstrates application invariants without claiming database isolation, throughput or crash recovery. Those controls require integration and recovery tests in the chosen platform.

Reviewed in this demonstration

Repeated event processing and fulfilment
Concurrent reservation of the last item
Order and amount reconciliation before migration cutover

E-COMMERCE DEMONSTRATION

Findings and verified changes

ARC-01Review priority: High

Repeated payment events create multiple dispatches

The demonstrated flow creates more than one shipment instruction for one paid order, risking duplicate fulfilment and manual reconciliation.

Observed finding: 3 deliveries of the same event create 3 dispatch instructions. The fixed transition creates 1.
Recommended fix: Make fulfilment repeatable without duplication. Record event identities durably and enforce a unique business fulfilment operation in the same transactional boundary as the state change.
Verification and follow-up checks: Replay the event and a differently identified event for the same operation. Expect one dispatch. In the live platform, also test concurrent consumers and crashes between persistence and dispatch hand-off.

Before the fix

Event deliveries: 3; dispatches: 3.

After the fix

Event deliveries: 3; dispatches: 1.

ARC-02Review priority: High

Two customers both reserve the last unit

Both checkouts receive a reservation promise for a single unit, producing an unfulfillable order in the model.

Observed finding: Both requests read stock before either updates it. The flow accepts 2 reservations and leaves stock at -1.
Recommended fix: Preserve the stock promise. Use an atomic conditional reservation or a transaction with appropriate locking; confirm success before accepting the order and define reservation expiry and compensation.
Verification and follow-up checks: Run competing requests with one available unit: one succeeds and one cannot reserve. Repeat with real database transactions, cancellation and timeouts; maintain non-negative stock and matching reservation records.

Before the fix

Accepted reservations: 2; remaining stock: -1.

After the fix

Accepted reservations: 1; remaining stock: 0.

ARC-03Review priority: High

Migration loses an order and truncates monetary values

Missing pending orders and changed amounts prevent reliable reconciliation. A cutover based on this conversion would carry incorrect order state into the new system.

Observed finding: The source has 3 orders totalling EUR 30.33. The flawed conversion keeps 2 orders totalling EUR 29.00.
Recommended fix: Preserve the order ledger. Define exact amount conversion and a complete status mapping, then reconcile identifiers, amounts, currencies and state per order. Block cutover when any invariant differs.
Verification and follow-up checks: Compare every source order with its target and totals by currency. Deliberately introduce a missing order, changed amount and changed status: reconciliation must prevent cutover. Rehearse with representative data and recovery checks.

Before the fix

Orders: 2/3; total: EUR 29.00; cutover blocked.

After the fix

Orders: 3/3; total: EUR 30.33; all model invariants match.

What this helps you decide

Assign one authoritative owner to order, payment and stock state before introducing another service.
Use atomic transitions and durable idempotency; moving to microservices alone does not establish consistency.
Migrate in stages with reconciliation, explicit go/no-go criteria and a rehearsed rollback or recovery path.

What the review produces

An invariant checklist and migration sequence covering ownership of state, repeatable processing, reconciliation and cutover gates.

Technical references

The references explain the control principles. The observations above come from the local demonstration.

Explore the other reviews

All review insights

01 / E-COMMERCE DEMONSTRATION

E-commerce security: protect orders and payments

Can an order be read or fulfilled without the right customer or a verified payment?

What the review produces

A prioritized finding register, concrete control changes and regression checks for the customer-to-payment journey.

Read findings and verification

02 / E-COMMERCE DEMONSTRATION

E-commerce delivery: release the change that was checked

Can a release proceed after failed checks, change after approval or expose secrets through logs?

What the review produces

A release-control checklist with required evidence, artifact verification and a safe diagnostic record.

Read findings and verification

CONTACT

Discuss your audit scope.

Start with the business question, a general description of the system and your preferred dates. We agree confidentiality and information handling before you share technical materials.

Select a button to reveal the email address or phone number.

Based in Poland. On-site audits in Poland and internationally are available by arrangement.

Prepare for an audit