Shopping Cart

Assume 40M daily active shoppers, 25 percent of them modify a cart on a typical day, an average of 4 cart mutations per modifying shopper, and a 10x peak multiplier during large sales. Assume 30M active carts retained at any time across guests and authenticated users.

Assume an average cart has 8 line items. A cart header is about 600 bytes and each line item is about 300 bytes after including sku, quantity, selected options, seller, timestamps, version, and small validation hints. That makes the average cart about 3 KB before database indexes and cache overhead.

• Mutating shoppers: 40M daily active shoppers times 25 percent is 10M shoppers who change a cart each day.
• Writes: 10M mutating shoppers times 4 mutations is 40M cart writes per day. 40M divided by 86,400 seconds is about 463 writes per second on average. A 10x sale multiplier gives roughly 4,630 writes per second, rounded to 4,600 to 5,000.
• Reads: cart pages, header badges, mini-carts, and device refreshes create more reads than writes. At about 5 reads per write, 40M writes produce about 200M reads per day. 200M divided by 86,400 seconds is about 2,315 reads per second average and about 23,000 to 25,000 at peak.
• Storage: an average cart is 600 bytes of header plus 8 line items times 300 bytes, or about 3,000 bytes. 30M active carts times 3 KB is about 90 GB raw active state.
• Durable footprint: 90 GB raw with 3 replicas is 270 GB. Indexes, tombstones, recent cart events, and compaction headroom raise this to about 350 to 450 GB.
• Cache: if the hottest 8M carts are in Redis, 8M times 3 KB is about 24 GB raw. Redis object overhead, fragmentation, replication, and memory headroom make 60 to 80 GB a safer cache budget.
• Checkout handoff: if 2M carts reach checkout per day, average checkout-start QPS is about 23 per second, with peak around 250 per second. This is lower than cart mutation traffic but requires stronger correctness.

• carts.cart_id is the primary key for direct cart reads and writes.
• carts.user_id, status, updated_at finds the active authenticated cart and supports customer service views.
• carts.guest_session_id, status finds an anonymous cart from a signed guest cookie.
• carts.expires_at supports TTL sweeps for abandoned carts.
• cart_items.cart_id, sku_id supports merging duplicate SKUs and reading all line items for a cart.
• cart_events.cart_id, created_at supports replay and debugging without scanning all events.
• cart_events.idempotency_key should be unique within a cart or actor scope.

One active authenticated user usually has one active cart per marketplace, region, or business line. One cart has many line items. A guest cart can be merged into an authenticated cart and then marked merged so it is not reused. Checkout snapshots reference the cart and cart version but should be immutable after creation.

A document store or key-value store is a natural fit because a cart is usually fetched and written as a small aggregate. Store the active cart document by cart_id, and maintain lookup records from user_id or guest_session_id to the active cart id.

DynamoDB can use a partition key such as cart_id with line items as items under the same partition, or store one compact cart document if the item count is bounded. Cassandra can partition by cart id and cluster by line item id. Redis is excellent for hot state and TTL, but it should not be the only source of truth for authenticated carts unless the business accepts cache-loss data loss.

Anonymous carts are usually keyed by a signed, opaque guest session id stored in a cookie or mobile local storage. They should not trust client-provided item prices or user ids. The server owns the cart id, signs the guest token, and applies TTL because anonymous state is easy to accumulate and expensive to retain forever.

Authenticated carts are keyed by user id and often partitioned by marketplace, region, or business line. They need stronger durability because shoppers expect the cart to follow them across devices. When a guest logs in, the system must merge rather than blindly replace. The safest policy is deterministic: load guest cart and user cart, combine distinct line items, merge identical SKU and option combinations by summing quantities up to a product limit, preserve the most recent selected options when they conflict, and return conflict details.

Avoid two common mistakes. First, do not drop the authenticated cart just because a fresher guest cart exists; a returning user may have saved intent from another device. Second, do not keep both carts active after login; mark the guest cart merged and idempotently remember the merge request so retries do not double quantities.

Redis is attractive because cart reads and writes are small, frequent, and latency-sensitive. It supports TTL naturally and can serve mini-cart refreshes with low latency. However, Redis alone is risky for authenticated carts unless configured with persistence and replication and unless the business accepts rare loss. A durable database should remain the source of truth for carts that matter.

A practical write path is write-through: validate the mutation, update the durable cart record with an optimistic version condition, then update Redis and publish an event. If Redis fails after the database write, the API can still succeed and let future reads warm the cache. If the database write fails, do not acknowledge the mutation for authenticated carts. Guest carts may use a write-behind optimization during extreme traffic, but the product must accept that a cache loss can lose some anonymous carts.

The cart record should be bounded. Store the current snapshot and recent idempotency keys in the hot record, but move large event history, recommendation metadata, and analytics to separate stores. This keeps the p99 path predictable.

Adding an item to a cart should not reserve inventory forever or freeze price forever. It records shopper intent plus the best known price and availability at that moment. This lets the UI say the item was 19.99 when added and now is 20.99, which is transparent and avoids surprising checkout totals.

Availability at add time is also a hint. For high-demand items, stock may disappear seconds later. If the system reserved inventory on every add-to-cart, abandoned carts would lock stock away from real buyers. Instead, use soft checks while shopping and reserve only at checkout, for a short window such as 10 to 15 minutes.

At checkout, the service must call authoritative pricing, promotions, tax, shipping, and inventory. If the price changed, the item became unavailable, or the requested quantity exceeds stock, return an item-level conflict and let the shopper accept changes. The cart service should not silently mutate totals and proceed to payment.

A shopping cart is a classic eventually consistent example because a perfect global total order is usually not worth the latency. If a shopper adds headphones on a phone and a charger on a laptop, the desired result is both items. Last-write-wins at the whole-cart level can lose one device's intent.

Use mergeable operations where possible: add item, remove item, set quantity, and update option. Track a cart version and per-line item versions. Distinct line items can be unioned. For the same line item, quantity changes need a policy: last-write-wins is simple for set quantity, while additive increments are better represented as operations with idempotency keys. Removes should carry a timestamp or tombstone so an old add event does not resurrect a deleted item.

For most interviews, choose eventual consistency across devices with optimistic concurrency at the cart aggregate. Return the latest version on conflict and let the client retry or merge. Reserve stronger consistency for checkout, where duplicate orders and overselling are not acceptable.

Carts have lifecycle states: active, merged, converted, abandoned, and expired. Guest carts may expire after 7 to 30 days. Authenticated carts may be retained for 90 to 180 days, but every render should refresh stale price and availability hints. Converted carts can be retained as snapshots for customer support or order attribution, then archived.

TTL belongs in both cache and durable storage. Redis should expire hot entries automatically. The durable store should have an expiry index or native TTL feature, plus a worker that marks carts abandoned, deletes old guest state, and emits analytics. Use soft deletion when legal, fraud, or customer support requirements need history.

Abandonment workflows should be asynchronous. The cart path emits events, and a worker sends reminders, updates analytics, or triggers recommendations. If the worker is down, cart mutation and checkout must continue.

The cart is mutable and user-controlled; checkout is controlled and auditable. The handoff creates a checkout snapshot containing items, quantities, current prices, promotions, shipping information, tax inputs, and the cart version. That snapshot should be immutable so payment, order creation, and customer support see the same data.

Inventory reservation should happen during checkout, not during add-to-cart. The reservation has an expiry, commonly 10 to 15 minutes, and is released if payment fails or the shopper abandons checkout. Use idempotency keys so retrying checkout does not create multiple reservations for the same cart version.

After successful order creation, mark the cart converted or clear purchased items. Do not delete the cart before order creation is durable, because payment retries and customer support may need the snapshot.

Alternative one is cache-only carts. This is very fast and simple for anonymous shopping, but it risks losing authenticated carts and makes support difficult after incidents.

Alternative two is database-only carts. This is durable and simpler to reason about, but repeated mini-cart reads and sale traffic can overload the database unless the system adds read replicas or aggressive client caching.

Alternative three is event-sourced carts. Every mutation is appended and snapshots are derived. This gives excellent audit and merge history, but it is more complex and usually unnecessary unless the product needs collaborative carts, deep audit, or advanced conflict resolution.

Do not use this mutable shopping cart design as the source of truth for orders, payments, or inventory ownership. Once the shopper starts checkout, move to immutable checkout snapshots, inventory reservations, payment intents, and order records with stronger consistency and audit requirements.