04QuestionsOnline bookstore

04 · Worked prompt

Online bookstore

Design catalog search, inventory, carts, orders, reservations, and payment-safe checkout.

30 minInterview blueprint

INTERVIEW RUBRIC

What a passing answer must show

100 points · 45 minutes

20pts
Scope the problem
0–5 min
Prioritize the core flows, state the scale, and name the non-goals.
15pts
Define contracts
5–10 min
Identify durable entities, APIs, idempotency, and the source of truth.
30pts
Complete the diagram
10–25 min
Trace one write path and one read path. Label the commit boundary and async work.
20pts
Lead one deep dive
25–38 min
Choose the highest-risk trade-off and explain the mechanism, alternative, and cost.
15pts
Prove reliability
38–45 min
Walk a failure, recovery, metric, bottleneck, and evolution path.

DRAW THIS FIRST

One complete box-and-arrow design

Design catalog search, inventory, carts, orders, reservations, and payment-safe checkout.

Online bookstore system architecture. Orders and inventory holds commit transactionally; payment and fulfillment converge through explicit states. Request path: Storefront clients to Commerce API to Checkout orchestrator to Order/inventory DB. Asynchronous path: Order event bus to Fulfillment workers. Read path: Catalog service to Catalog search index. External dependency: Payment processor. — Online bookstore · system architecture

DEFEND THE DIAGRAM

Explain every boundary before adding more boxes.

Orders and inventory holds commit transactionally; payment and fulfillment converge through explicit states.

INTERVIEW CONTRACT

Design catalog search, inventory, carts, orders, reservations, and payment-safe checkout.

CAPACITY QUESTIONS TO QUANTIFY

Read-heavy catalog · sale spikes · strict inventory · external payment latency. State average and peak load, stored bytes, bandwidth or open connections, and the growth horizon before choosing a partitioning strategy.

End-to-end walkthrough

Trace the architecture in this order.

01
Enter and classify the request
Storefront clients → Commerce API
Search, cart, checkout enters over HTTPS / RPC. Commerce API handles identity, admission, routing, and request context; it deliberately does not own domain truth.
02
Validate, then cross the commit boundary
Commerce API → Checkout orchestrator → Order/inventory DB
Checkout orchestrator receives the command, checks invariants and retry identity, then uses inventory transaction to update Order/inventory DB. The user-visible mutation is accepted only after this boundary succeeds.
03
Move replayable work off the request path
Checkout orchestrator → Order event bus → Fulfillment workers → Catalog search index
Checkout orchestrator emits publish after commit; Fulfillment workers uses consume and project / update to build Catalog search index. Consumers must tolerate duplicate delivery and stale retries because this path is asynchronous.
04
Serve reads from the right authority
Commerce API → Catalog service → Catalog search index / Order/inventory DB
Catalog service uses search + hydrate for the common, read-optimized path and strong read when correctness or repair requires authoritative state. The API must state the freshness promise instead of hiding it.
05
Contain the dependency boundary
Checkout orchestrator → Payment processor
idempotent payment crosses into Payment processor. Treat timeouts as ambiguous, use a deadline and idempotent retry or reconciliation, and keep the core state recoverable when the dependency is unavailable.

Ownership ledger

Why each box exists—and what it must defend.

Component	Owns	Why it exists	Interviewer probe
Commerce APIAuth + cart context	Identity, admission, routing	Protects the system edge and attaches trusted context before domain work begins.	Timeout budgets, quotas, regional routing
Checkout orchestratorHold stock + authorize payment	Write invariants and retry identity	Serializes or conditionally applies state changes before acknowledging success.	Concurrent writes, deduplication, hot ownership
Order/inventory DBHolds, orders, stock	Authoritative durable state	Provides the one record used to resolve disputes, recover, and rebuild projections.	Partition key, replication, consistency
Order event busConfirmed/cancelled events	Durable asynchronous handoff	Absorbs bursts and lets slow or optional work retry independently of the request.	Ordering key, lag, retention, dead letters
Fulfillment workersReserve, release, ship	Replayable processing	Runs expensive, fan-out, or side-effecting work with leases and bounded retries.	Idempotency, poison work, autoscaling
Catalog search indexProducts + availability view	Rebuildable query state	Shapes data for the dominant reads without weakening the write-side invariant.	Freshness, versioning, rebuild time
Catalog serviceSearch + availability	Read composition and freshness policy	Chooses authoritative or derived state and returns a stable client contract.	Fan-out, cache policy, partial results
Payment processorAuthorize/capture/refund	External capability, not local truth	Keeps a specialized or third-party concern behind a replaceable contract.	Ambiguous timeout, circuit breaking, fallback

Physical design

Name the database, shard key, indexes, and guarantees.

Database + storage: PostgreSQL owns inventory, carts, orders, reservations, and payment intent; OpenSearch serves catalog; Redis caches product/session reads.
Partitioning / sharding: Orders shard by customer/order ID; inventory ownership uses SKU + location. Search shards independently by product document.
Indexes: Unique checkout key, inventory (sku, location), order history (customer_id, created_at), and full-text/facet fields in OpenSearch.
Replication + consistency: Inventory reservation and order ledger are strong. Catalog/search is eventual; checkout always revalidates stock in the transaction.
Cache, queue + recovery: An outbox updates search, notifications, fulfillment, and expiry workers. Cache product details by source version.
Capacity math: Estimate catalog size, search QPS, checkout peak, order lines, hot-SKU contention, reservation TTL, and index lag.
Alternative rejected: One SQL store starts well, but transactional inventory and relevance search diverge; keep SQL truth and a rebuildable index.

Deep-dive candidates

Pick one risk and explain the mechanism, alternative, and cost.

Inventory hold

Conditionally decrement available and increment reserved under SKU ownership with TTL

A read-time availability check cannot prevent oversell

Checkout saga

Persist every step and compensate holds or authorization on failure

Distributed checkout is not one database transaction

Search freshness

Index catalog asynchronously but verify price and availability from owners before checkout

Discovery may be stale; purchase cannot be

Failure pressure test

Show detection, containment, recovery, and evidence.

Payment timeout

Query provider by idempotency key before retry

ambiguous payment count

Hold expires mid-payment

Version-check confirmation and void late authorization

expired checkout count

Search lag

Serve stale discovery with freshness tolerance but never stale final price

index lag

Before you finish, explicitly cover

Functional requirements and non-goals
Peak traffic, storage, bandwidth, and growth
Entities, APIs, idempotency, and pagination
Source of truth and consistency promise
Partition key, replicas, caches, and hot spots
Retries, backpressure, failover, and reconciliation
Latency, saturation, correctness, and recovery metrics
Security, migration, cost, and multi-region evolution

SAY THIS WHILE YOU DRAW

A four-part talk track

Scope
“I’ll prioritize search and browse a large catalog and maintain carts and price snapshots.”
Scale
“The design changes around read-heavy catalog · sale spikes · strict inventory · external payment latency.”
Decision
“Reserve stock before charging when inventory is scarce.”
Risk
“The first failure I want to pressure-test is: Duplicate checkout and out-of-order payment callbacks can create money or stock errors.”

Reference details

Open these only after you can explain the diagram above without reading.

01Requirements and state lifecycle4 requirements

Search and browse a large catalog
Maintain carts and price snapshots
Prevent overselling during checkout
Integrate payment with safe retries and clear order states

Online bookstore · state lifecycle

state lifecycle

Each transition must be durable, observable, and safe to retry.

pending

inventory held

payment authorized

confirmed

cancelled or refunded

02Data model and APIs4 entities · 3 interfaces

Core entities

Productproduct_id, seller_id, attributes, versionOwner: Catalog service

Inventorysku, available, reserved, versionOwner: Inventory service

Orderorder_id, buyer_id, lines, totals, stateOwner: Order service

PaymentIntentpayment_id, order_id, amount, provider_stateOwner: Payment service

External interfaces

GET /v1/search?q={query}&cursor={cursor}

Search a derived index

POST /v1/checkouts

Create checkout under an idempotency key

GET /v1/orders/{id}

Read order, hold expiry, and payment status

03Deep dives and trade-offsChoose one

Inventory hold

Conditionally decrement available and increment reserved under SKU ownership with TTL

A read-time availability check cannot prevent oversell

Checkout saga

Persist every step and compensate holds or authorization on failure

Distributed checkout is not one database transaction

Search freshness

Index catalog asynchronously but verify price and availability from owners before checkout

Discovery may be stale; purchase cannot be

04Failures, recovery, and evidence3 scenarios

Payment timeout

Query provider by idempotency key before retry

ambiguous payment count

Hold expires mid-payment

Version-check confirmation and void late authorization

expired checkout count

Search lag

Serve stale discovery with freshness tolerance but never stale final price

index lag

05What makes the answer seniorInterviewer signals

Separate browse availability from reservation correctness
The order state machine is the backbone of the answer
Say where tax, discounts, and price snapshots become immutable
Primary trade-off: Reserve stock before charging when inventory is scarce.

BEFORE THE NEXT QUESTION

Can you redraw it from memory?

Name the source of truth.
Trace the write and read paths.
Defend one trade-off.
Recover from one failure.

Scope the problem

Define contracts

Complete the diagram

Lead one deep dive

Prove reliability

Write

Propagate

Read

Trace the architecture in this order.

Enter and classify the request

Validate, then cross the commit boundary

Move replayable work off the request path

Serve reads from the right authority

Contain the dependency boundary

Why each box exists—and what it must defend.

Name the database, shard key, indexes, and guarantees.

Pick one risk and explain the mechanism, alternative, and cost.

Inventory hold

Checkout saga

Search freshness

Show detection, containment, recovery, and evidence.

Payment timeout

Hold expires mid-payment

Search lag

Reference details

Core entities

External interfaces

Inventory hold

Checkout saga

Search freshness

Payment timeout

Hold expires mid-payment

Search lag

Can you redraw it from memory?