1 · Seller discovery: live fan-out or internal offer catalog

Live fan-out

Query all eligible sellers for every order. Prices are fresh and onboarding is simple.

Weakness

At 10K QPS, multiplying each order by every seller overwhelms external APIs and amplifies tail latency. The first staff review illustrated 100 sellers as one million pricing calls per second.

Offer catalog

Ingest seller price and inventory updates, index by ISBN, and contact only a small candidate set for the final hold.

Weakness

Cached prices and inventory can be stale. A live hold remains mandatory before payment.

Best fit

Use a hybrid: push updates from capable sellers, poll smaller sellers, rank a short candidate list internally, then revalidate through the hold endpoint.

2 · Queue partitioning: book key, author key, or order key

Book ID / ISBN

Serializes updates and orders for one book. It supports fairness and deterministic matching.

Weakness

Popular books form hot partitions. Splitting the key weakens total ordering.

Author ID

The first staff design proposes author partitions and multiple lanes for popular authors.

Weakness

Unrelated books by one author block each other, and an ISBN-to-author lookup precedes routing.

Order ID

Evenly distributes independent workflows and avoids hot product keys.

Weakness

Inventory ordering moves to the seller hold or a conditional inventory write. This is acceptable when the seller remains the stock authority.

3 · Inventory coordination: local OCC, single writer, or seller hold

OCC

Versioned conditional writes prevent lost updates inside one inventory database.

Weakness

OCC across two services and multiple databases leaves ownership ambiguous. One reviewed design allowed both Book Service and Matching Service to reserve inventory.

Single writer

One Matching Service owns reserve, release, commit, and order-state mutation. Per-book stream ordering becomes a clear sequencing point.

Seller hold

When sellers also sell through their own shops, their hold endpoint becomes the real consistency boundary. It carries an expiry and survives stale platform inventory.

4 · Workflow ownership: Redis lock, DB compare-and-set, or durable orchestrator

Redis lock

A short lock can reduce duplicate upstream calls and dogpiles.

Weakness

Failover and expiry complicate correctness. Combining an offer cache key with a lock key was specifically criticized.

DB CAS

An atomic update such as SEARCHING → COMMITTING selects one winner. Competing workers observe zero updated rows and stop.

Orchestrator

One durable workflow per order serializes the state machine. External calls remain idempotent, and webhooks become workflow signals.

Best fit

Use DB CAS or workflow identity for correctness. Use Redis for cache, rate limits, and best-effort concurrency control.

5 · Payment boundary: platform coordination or seller settlement

Platform flow

Client tokenizes card details with Stripe. The platform creates a manual-capture PaymentIntent and directs funds to the seller account.

Strength

The workflow can authorize funds, wait for seller confirmation, then capture. Provider idempotency and webhooks support recovery.

Seller flow

The platform passes a payment token to the seller, who settles directly with the processor.

Strength

The seller owns inventory and transaction settlement. The platform carries less payment orchestration.

Boundary

Both approaches keep raw PAN and CVV outside platform storage. Product and merchant-of-record policy selects the final ownership model.

6 · Durable dispatch: scanner recovery or transactional outbox

DB then queue

The first staff design writes the order, enqueues it, and runs a scanner that republishes stuck pending orders.

Outbox

One database transaction writes the order and an outbox record. A publisher delivers the event later.

Tradeoff

Both recover lost dispatch. The scanner is simple and periodic; the outbox gives a direct durable record of every undispatched event.