Shopping carts are one of the oldest metaphors in e-commerce, and also one of the most quietly complicated engineering problems on any retail platform. What looks like a simple “list of items” on the surface hides a genuine distributed-systems challenge underneath — and that is exactly what makes this problem a favorite for system design interviews.

In the earliest days of the web, a “cart” was nothing more than a browser cookie or a server-side session — the moment you closed the tab or switched to a different computer, the cart was gone. That was acceptable in an era when most people shopped from a single desktop computer. It is completely unacceptable today, when the average shopper moves fluidly between a phone on the train, a tablet on the couch, and a laptop at a desk, often within the same hour, and expects their cart to simply follow them.

The shift began in the mid-2000s as e-commerce companies started tying carts to logged-in user accounts instead of anonymous browser sessions, so a cart could at least survive a login on a different device. But “surviving a login” and “syncing in real time” are very different engineering problems. Early cross-device carts required a manual page refresh to see items added elsewhere. Real, live synchronization — where an item added on a phone appears on an already-open laptop tab within a second or two, with no refresh — is a genuinely modern capability, built on the same real-time infrastructure (WebSockets, push notification services, event streaming) that also powers live chat, multiplayer games, and collaborative documents.

This class of problem sits at the intersection of two classic distributed systems challenges: state synchronization (keeping the same logical piece of data consistent across multiple independent copies) and conflict resolution (deciding what to do when two devices change the same data at nearly the same moment, such as a phone and a laptop both trying to change the quantity of the same item within a second of each other). Both problems have been studied for decades in distributed databases and real-time collaborative software, and this guide borrows heavily from that body of knowledge — CRDTs, vector clocks, eventual consistency, and optimistic concurrency — and applies it specifically to something as everyday as a shopping cart.

A short history of cart evolution

Over the last decade, nearly every major retailer — Amazon, Walmart, Target, eBay, Shopify-powered storefronts — has invested heavily in this exact capability, because a cart that doesn’t follow the shopper directly threatens revenue: if someone adds three items on their phone during a commute and then can’t find them later on their laptop, a meaningful percentage of those shoppers simply never complete the purchase at all. This guide walks through designing that system end to end.

2.1 Precise problem statement

Design a shopping cart backend where:

• A logged-in user can add, remove, or change the quantity of items from any device (phone, tablet, laptop, in-store kiosk).
• Every other device the same user currently has open reflects that change within roughly one to two seconds, without a manual refresh.
• The cart persists indefinitely (or until checkout/expiry) even if all devices are closed — reopening any device later still shows the correct, latest cart.
• Concurrent edits from two devices at nearly the same instant are resolved sensibly, without silently losing an item one of the devices added.
• The system stays correct and available even under partial failures — a flaky mobile network, a dropped WebSocket connection, a backend node restarting mid-request.

2.2 Why this is harder than it sounds

At first glance, a shopping cart looks like “just a list stored in a database.” The difficulty comes from three compounding factors:

2.3 What “good” looks like

2.4 Functional requirements

Before drawing any boxes and arrows, it helps to write down, in plain language, exactly what the system must be able to do. This becomes the checklist every architectural decision downstream gets measured against.

• Add, remove, and update-quantity operations on cart line items, from any authenticated device.
• Real-time propagation of changes to every currently connected device belonging to the same user.
• Durable persistence of the cart independent of any specific device or session.
• Deterministic, product-aware conflict resolution when concurrent edits collide.
• Safe offline queuing on mobile clients with automatic replay on reconnect.
• A stricter, blocking-consistency mode specifically during checkout.
• Re-validation of price and stock at both add-time and checkout, never trusting client-supplied pricing.

Every term below reappears constantly in the rest of this guide, so take the time to internalize each one with its analogy. By the end of Section 04, none of the labels on the architecture diagram should feel unfamiliar.

3.1 WebSockets

What it is: A persistent, two-way network connection between a client and a server that stays open, allowing either side to send messages at any time without the client needing to repeatedly ask “anything new?” Why it exists: Traditional HTTP requires the client to initiate every exchange; WebSockets let the server push data the instant something changes. Where it’s used: Live chat apps, multiplayer games, stock tickers, and cross-device cart sync. Analogy: A regular HTTP request is like mailing a letter and waiting for a reply letter each time you have a question. A WebSocket is like an open phone line that stays connected, so either person can speak up the moment they have something to say. Example: A laptop keeps an open WebSocket connection to the Cart Sync Service; the instant the phone adds an item, the server pushes a small “cart updated” message down that same open connection to the laptop.

3.2 Eventual consistency

What it is: A consistency model where, after writes stop occurring, all replicas of a piece of data will eventually converge to the same value — but at any given instant, different replicas might briefly disagree. Why it exists: Enforcing perfect, instant agreement across every replica on every write (strong consistency) is expensive and can hurt availability; eventual consistency trades a small, usually sub-second window of possible disagreement for much better availability and performance. Where it’s used: Shopping carts, social media like-counts, DNS. Analogy: If you tell three friends the same piece of news by phone one after another, there’s a brief window where one friend knows and the other two don’t yet — but within a few minutes, all three know the same thing. Example: The instant after adding an item on mobile, the laptop’s locally cached cart view might be stale for a fraction of a second until the push notification and refreshed data arrive.

3.3 Conflict-Free Replicated Data Types (CRDTs)

What it is: A family of data structures specifically designed so that multiple copies can be updated independently and later merged automatically into a consistent result, with no coordination required at write time and no possibility of a merge conflict. Why it exists: In a system where two devices can edit the same cart while offline from each other, you need a mathematically guaranteed way to merge their changes back together without manual conflict resolution. Where it’s used: Collaborative text editors (like Google Docs’ underlying sync tech), distributed databases like Redis with CRDT support, and shopping carts. Analogy: Imagine two people independently adding stickers to two copies of the same sticker book while apart; if the rule is simply “the final book contains every sticker either person added,” merging the books later is trivial and never creates a conflict — that’s the spirit of a CRDT, applied to cart line items. Example: A cart modeled as a CRDT “grow-only set with removal tombstones” lets each device add items freely offline; merging two devices’ changes later simply unions the additions and applies any removals, with a well-defined rule for what happens if the same item was both added and removed by different devices.

3.4 Optimistic UI updates

What it is: Updating the user interface immediately when the user takes an action (like tapping “Add to Cart”), before waiting for server confirmation, then quietly correcting the UI if the server ultimately rejects or modifies the change. Why it exists: Waiting for a full network round-trip before showing any feedback makes an app feel slow and unresponsive; optimistic updates make the app feel instant. Where it’s used: Nearly every modern mobile app, including cart and “like” buttons. Example: Tapping “Add to Cart” instantly shows the item in the cart icon’s count, while the actual server write happens in the background milliseconds later.

3.5 Idempotency

What it is: A property of an operation meaning that performing it multiple times has the same effect as performing it once. Why it exists: Unreliable networks mean a client sometimes can’t tell whether a request succeeded or simply the response was lost; if the client safely retries, idempotency guarantees the retry doesn’t cause a duplicate effect (like adding the same item twice by accident). Where it’s used: Payment processing, cart mutations, any operation that might be retried. Example: An “add item” request carries a unique client-generated request ID; if the same request ID arrives twice (because the client retried after a timeout), the server recognizes the duplicate and applies the change only once.

3.6 Vector clocks / logical versioning

What it is: A mechanism for tracking the relative order of events across multiple independent devices without relying on wall-clock time (which can differ slightly between devices), typically by attaching a version number or a small per-device counter to every change. Why it exists: Wall-clock timestamps from different devices can’t always be trusted to determine “which change happened first,” especially with clock drift; logical versioning gives a more reliable way to detect and order conflicting changes. Where it’s used: Distributed databases like DynamoDB and Riak, collaborative applications. Example: Each cart carries a version number that increments on every change; when a device submits an update, it includes the version it last saw — if that version is stale by the time the update reaches the server, the server knows a conflicting change happened elsewhere first and can trigger the merge logic.

3.7 Push notification / fan-out service

What it is: A service responsible for delivering a message to all of a user’s currently-connected devices, not just one. Why it exists: A user might have the app open on three devices simultaneously; a cart change needs to reach all of them, not just the device that isn’t currently the one that made the change. Example: After a phone adds an item, the Fan-out Service looks up every open WebSocket connection registered to that user ID and pushes the update to each one, including the phone itself (for confirmation) and the laptop.

3.8 Distributed locking

What it is: A mechanism that ensures only one process (or device, in this context) can hold exclusive access to a specific piece of data at a time, implemented in a way that works correctly even though the “processes” involved are running on entirely separate machines with no shared memory. Why it exists: Some operations — most notably checkout, discussed in Section 07.4 — are too risky to leave to eventual consistency and instead need a brief window of exclusive access to guarantee correctness. Where it’s used: Checkout flows, inventory reservation systems, distributed job schedulers. Analogy: A “occupied” sign on a single-user restroom is a simple distributed lock — anyone approaching sees the sign and waits, rather than two people trying to use the same space at once, and the sign is removed (the lock released) as soon as the person is done. Example: DynamoDB’s conditional write feature is used to implement a short-lived “checkout in progress” lock on a cart, ensuring no other device can mutate that cart’s contents until checkout completes or the lock expires.

Below is the full architecture. Every box names exactly what kind of component it is — client, edge, gateway, load balancer, service, cache, database, or queue — so nothing is ambiguous.

Let’s walk through each layer.

5.1 Step-by-step walkthrough: adding an item on mobile

5.2 What happens when a device is offline

If the mobile device is offline when the user taps “Add to Cart,” the optimistic UI update still happens locally, but the request queues locally on the device instead of being discarded. When connectivity returns, the client replays the queued request (using its idempotency key, so it’s safe even if part of it had actually gone through before the connection dropped). If the cart changed on another device in the meantime, the version mismatch triggers the Conflict Resolution Service, which merges the offline device’s queued change with whatever happened elsewhere.

5.3 Why every step matters

Each step above corresponds to one architectural decision worth defending in an interview. The optimistic UI update earns responsiveness at the cost of a small reconciliation risk. The idempotency key earns safe retries at the cost of the client having to generate and remember a stable ID. The version check earns cheap conflict detection at the cost of the client having to track the version. The durable write earns correctness at the cost of one extra round trip before acknowledgement. The fan-out earns cross-device propagation at the cost of maintaining a connection registry. Together they form a coherent whole — but each individual choice would look arbitrary if isolated from the rest.

6.1 Cart lifecycle states

6.2 Read path vs. write path

The read path (opening the cart page, refreshing the cart icon count) is designed for the fast, common case: Redis first, DynamoDB on a miss, with the response served in a few milliseconds. The write path (add/remove/quantity change) is designed for correctness: it always goes through the version check, the durable write, and the fan-out. Separating these two mental models — even though they touch the same components — is what keeps the design coherent as new features (wishlists, save-for-later, shared carts) get layered on top of it.

7.1 Optimistic concurrency control with version numbers

The simplest and most widely used approach: every cart carries a monotonically increasing version number. A client must include the version it last read when submitting a change; if the server’s current version doesn’t match, the write is rejected and the conflict resolution path kicks in instead of silently overwriting data.

public class CartVersionCheck {

    public static class VersionConflictException extends RuntimeException {
        public VersionConflictException(String message) {
            super(message);
        }
    }

    // Attempts a conditional write; throws if the version has moved on
    public CartRecord applyChange(CartRecord currentServerCart,
                                   CartChangeRequest request) {

        if (currentServerCart.getVersion() != request.getExpectedVersion()) {
            // Someone else changed the cart since this client last read it
            throw new VersionConflictException(
                "Expected version " + request.getExpectedVersion() +
                " but server is at version " + currentServerCart.getVersion());
        }

        CartRecord updated = currentServerCart.copy();
        updated.applyItemChange(request.getItemId(), request.getQuantityDelta());
        updated.setVersion(currentServerCart.getVersion() + 1);
        updated.setLastModifiedTimestamp(System.currentTimeMillis());
        updated.setLastModifiedDeviceId(request.getDeviceId());

        return updated;
    }
}

7.2 CRDT-style merge for offline-tolerant conflict resolution

When a version conflict is detected (or when reconciling a device that queued changes while offline), a naive “last write wins” approach risks silently discarding a legitimate addition from one of the two devices. A CRDT-inspired merge instead treats the cart as a set of line-item operations that can be combined deterministically, regardless of the order they arrive in.

import java.util.*;

public class CartCrdtMerger {

    public static class LineItem {
        String itemId;
        int quantity;
        long lastModified;
        String deviceId;

        LineItem(String itemId, int quantity, long lastModified, String deviceId) {
            this.itemId = itemId;
            this.quantity = quantity;
            this.lastModified = lastModified;
            this.deviceId = deviceId;
        }
    }

    // Merge two cart states (e.g. server's authoritative cart and a
    // device's locally-queued offline changes) into one reconciled cart.
    public Map<String, LineItem> merge(
            Map<String, LineItem> cartA,
            Map<String, LineItem> cartB,
            Set<String> removedItemIdsA,
            Set<String> removedItemIdsB) {

        Map<String, LineItem> merged = new HashMap<>();
        Set<String> allItemIds = new HashSet<>();
        allItemIds.addAll(cartA.keySet());
        allItemIds.addAll(cartB.keySet());

        for (String itemId : allItemIds) {
            boolean removedInA = removedItemIdsA.contains(itemId);
            boolean removedInB = removedItemIdsB.contains(itemId);
            LineItem itemFromA = cartA.get(itemId);
            LineItem itemFromB = cartB.get(itemId);

            if (removedInA && removedInB) {
                continue; // both removed it - stays removed
            }
            if (removedInA && itemFromB != null
                    && itemFromB.lastModified > removedTimestamp(removedItemIdsA, itemId)) {
                merged.put(itemId, itemFromB); // B re-added after A's removal
                continue;
            }
            if (removedInB && itemFromA != null
                    && itemFromA.lastModified > removedTimestamp(removedItemIdsB, itemId)) {
                merged.put(itemId, itemFromA); // A re-added after B's removal
                continue;
            }
            if (removedInA || removedInB) {
                continue; // one side removed, the other never re-added
            }

            // Neither side removed it - merge by taking the higher-quality winner
            if (itemFromA != null && itemFromB != null) {
                LineItem winner =
                    itemFromA.lastModified >= itemFromB.lastModified ? itemFromA : itemFromB;
                merged.put(itemId, winner);
            } else {
                merged.put(itemId, itemFromA != null ? itemFromA : itemFromB);
            }
        }

        return merged;
    }

    private long removedTimestamp(Set<String> removedSet, String itemId) {
        // In a real implementation, tombstones carry their own timestamp;
        // simplified here for clarity.
        return 0L;
    }
}

The key design decision worth calling out: this merge strategy treats additions as generally safe to preserve and uses timestamped tombstones to make sure a removal isn’t accidentally undone by a stale, late-arriving add from a device that was offline when the removal happened — and vice versa. This is a deliberate, product-level choice about what “correct” merge behavior means for a shopping cart specifically (favoring not losing something the user wanted to buy) rather than a purely mechanical one.

7.3 Choosing between strategies

7.4 The simultaneous checkout race

A particularly tricky edge case worth designing for explicitly: what if a user starts the checkout process on their laptop while, at the very same moment, they (or a shared-cart family member) removes an item from the same cart on their phone? If checkout has already locked in a snapshot of the cart before the removal arrives, the user could end up being charged for an item they just removed seconds earlier.

The standard solution is to treat checkout initiation as acquiring a short-lived, explicit lock on the cart — typically implemented as a conditional write in DynamoDB that sets a “checkout in progress” flag with a brief expiry (for example, five minutes, in case the user abandons checkout partway through). While this flag is set, any cart-mutation request from another device is either rejected with a clear “checkout in progress” response, or queued and applied only after the checkout completes or the lock expires. This is one of the few places in the entire system where the design deliberately favors strict consistency and blocking behavior over the eventual-consistency, always-available approach used everywhere else, precisely because the financial stakes at that specific moment are high enough to justify the trade-off.

8.1 Key trade-off: WebSockets vs. polling

Most production systems use WebSockets (or a similar push mechanism like Server-Sent Events) for the actively-open-app case, while falling back to a lightweight “refresh on app foreground” check for cases where maintaining a persistent connection isn’t practical, such as a mobile app that’s been backgrounded for a long time.

8.2 Key trade-off: strong consistency vs. availability at checkout

Throughout normal browsing, the system favors availability and low latency (eventual consistency, optimistic UI) over strict consistency. But at the moment of checkout, correctness matters far more than speed — so the checkout flow deliberately re-reads the authoritative cart directly from DynamoDB (bypassing the Redis cache) and re-validates price and stock synchronously, accepting slightly higher latency in exchange for certainty that the user is charged for exactly what they intended to buy.

8.3 The two-priority system, made explicit

It is worth naming this pattern directly, because it is the single most important architectural idea in the entire design: the same system deliberately runs two different consistency modes at two different times. During the ninety-nine percent of the time when a user is browsing, adding, removing, or just leaving the tab open, the system prizes availability and responsiveness. During the small window when checkout begins, the system flips to prizing strict consistency and correctness. Recognizing that a system does not have to make one global consistency choice for all time — it can and often should make different choices for different operations within the same product — is a mark of a genuinely senior systems answer in an interview.

9.1 Scaling the WebSocket layer

The WebSocket Gateway is the component with the most distinctive scaling profile in this system: what matters is concurrent connection count, not just request throughput. A single gateway node can typically hold anywhere from tens of thousands to low hundreds of thousands of idle connections, depending on tuning, so horizontal scaling here is about adding more gateway nodes and distributing connections across them, tracked via the Redis connection registry so the Fan-out Service always knows which node holds which user’s connection.

9.2 Read path optimization

Cart reads (displaying the cart icon count, opening the cart page) are far more frequent than cart writes, so the Redis hot-cart cache is critical: most reads never touch DynamoDB at all. A cache-aside pattern is used — read from Redis first, fall back to DynamoDB on a miss, then repopulate Redis.

9.3 Write path optimization

Cart writes are relatively low-volume compared to, say, a social media like-button, so the write path is optimized more for correctness (version checking, conflict resolution) than raw throughput. DynamoDB’s built-in conditional writes (using the version number as a condition) provide an efficient, database-native way to implement the optimistic concurrency check from Section 7.1 without a separate locking mechanism.

9.4 Fan-out efficiency

Because most users have at most two or three simultaneously connected devices, fan-out is cheap per event — but at platform scale, with millions of concurrent carts, the aggregate volume of fan-out messages still matters. The Fan-out Service batches lookups against the Redis connection registry and uses a lightweight internal pub/sub mechanism between WebSocket Gateway nodes, so a single cart change reaches the correct node(s) directly rather than broadcasting to every gateway node in the fleet.

9.5 Capacity planning for WebSocket connections

Unlike a stateless REST service, where capacity planning centers on requests-per-second, the WebSocket Gateway’s capacity planning centers on three separate numbers that each matter independently: peak concurrent connection count, connection churn rate (how often connections open and close, which matters because each handshake has its own CPU cost), and message fan-out rate (how many push messages per second the fleet needs to deliver). A gateway node that comfortably handles a large number of mostly-idle connections can still become a bottleneck under a high churn rate — for example, during a mobile network transition event affecting many users simultaneously, such as a citywide cellular outage causing a wave of reconnections all at once. Capacity plans for this layer are typically validated with dedicated load tests that specifically simulate connection churn and reconnection storms, not just steady-state idle connection counts, since steady-state testing alone can miss exactly the failure mode most likely to occur during a real incident.

10.1 Handling WebSocket disconnects gracefully

Mobile networks are unreliable by nature — connections drop when switching from WiFi to cellular, entering elevators, or losing signal. The client is designed to detect a dropped WebSocket connection and automatically reconnect with exponential backoff, and on reconnection, explicitly requests a fresh full cart state (rather than assuming it missed nothing) to guarantee it’s fully caught up on anything that happened while disconnected.

10.2 Redundancy & replication

10.3 Guaranteeing no lost writes

The single most important reliability guarantee in this system is that a cart mutation the user believes succeeded must never silently vanish. This is achieved through the combination of: durable, replicated writes to DynamoDB before returning success to the client; idempotency keys so client retries after a timeout never cause duplicate or lost effects; and the Kafka change-event log acting as an independent, replayable record that can rebuild cart state if ever needed.

10.4 Backup & disaster recovery

Beyond replication, a complete disaster recovery strategy protects against scenarios replication alone doesn’t cover, such as accidental data corruption or a bug that writes bad data widely before anyone notices:

• Point-in-time recovery: DynamoDB’s point-in-time recovery feature allows restoring cart data to any point within a retention window, which is invaluable if a deployment bug corrupts cart records before it’s caught.
• Event log as a rebuild mechanism: Because every cart mutation is also durably logged to Kafka and archived in Cassandra, the full cart state for any user can theoretically be reconstructed by replaying their event history from scratch, providing an independent recovery path if the primary store is ever compromised.
• Region-level failover: If an entire primary region becomes unavailable, GeoDNS redirects traffic to a secondary region serving from its own DynamoDB Global Table replica; because replication is asynchronous, a small window of very recent writes may not yet have propagated, which the system explicitly accepts as a deliberate availability-over-consistency trade-off during a regional outage.
• Regular restore testing: Backup and recovery procedures are periodically tested end to end in a non-production environment, since an untested backup is not a reliable one.

11.1 Authenticating WebSocket connections

Unlike a REST request, which carries an auth token on every single call, a WebSocket connection authenticates once at handshake time and then stays open, potentially for hours. The WebSocket Gateway validates the session token during the initial handshake, and the connection is tied to that authenticated user ID for its entire lifetime; if the underlying session is revoked (e.g., the user logs out), the gateway proactively closes the connection rather than waiting for it to naturally expire.

11.2 Preventing cart tampering

Every cart mutation request is scoped strictly to the authenticated user’s own cart — the Cart Service always derives the cart ID from the authenticated session, never from a client-supplied cart ID, preventing one user from being able to guess or manipulate another user’s cart by tampering with request parameters.

11.3 Price integrity

The client never supplies the price of an item when adding it to the cart — only the item ID and desired quantity. The server always looks up the authoritative current price from the Pricing & Inventory Service. This closes off an entire class of attack where a manipulated client could otherwise attempt to add an item at an artificially low, client-supplied price.

11.4 Rate limiting

The API Gateway enforces per-user rate limits on cart mutation endpoints, both to protect backend capacity and to blunt automated abuse (such as a script rapidly adding and removing items to probe for race conditions or inventory information).

11.5 Encryption in transit and at rest

Traffic between clients and the Load Balancer is served over TLS. Internal service-to-service calls use mutual TLS with short-lived certificates, so a single compromised service cannot impersonate another. Data at rest in DynamoDB, Redis, PostgreSQL, and Cassandra is encrypted using platform-managed keys, keeping cart contents protected even if physical storage is ever compromised.

Sync latency is the single most important metric unique to this system — it directly measures whether the core promise (“your cart follows you instantly”) is actually being kept, and is typically tracked as an end-to-end measurement: timestamp when a write is confirmed on the originating device, versus timestamp when the push update is received and rendered on a second connected device.

12.1 Logging & tracing

Every cart mutation carries a shared traceId propagated from the client through the Load Balancer, API Gateway, Cart Service, Conflict Resolution Service, and Fan-out Service, enabling a single distributed trace to show exactly how long a specific request spent in each layer — indispensable when debugging why one specific user’s cart update reached their other device forty seconds late instead of within the usual two.

12.2 Alerting without fatigue

Not every anomaly deserves a page. Alerts are tiered: P0 for end-to-end sync latency SLO breaches or a Cart Service that’s failing writes outright, since these represent the system failing at its core job during a live shopping session. P1 for elevated conflict rate, climbing consumer lag on the Kafka change-event topic, or WebSocket reconnection storms that haven’t yet degraded the user experience but are trending badly. P2 for slower-moving quality metrics like a gradual drift in cache hit rate, surfaced in a daily digest rather than an overnight page. Every P0 alert links directly to a runbook with concrete diagnostic queries, because the middle of a real incident is the worst possible time to be improvising a checklist.

13.1 Containerization & orchestration

Each service (Cart Service, Conflict Resolution Service, Fan-out Service, Pricing & Inventory Service) runs as a container on Kubernetes, providing automated scaling, self-healing, and rolling deployments. The WebSocket Gateway, due to its stateful, long-lived-connection nature, requires additional care during deployments — rolling out a new version must drain connections gracefully (allowing clients to reconnect to a new node) rather than abruptly severing them.

13.2 Multi-region considerations

DynamoDB Global Tables (or an equivalent multi-region replicated store) allow a user’s cart to be written in whichever region they’re physically closest to, with changes replicating to other regions asynchronously — meaning a user who adds an item while traveling and switches regions between devices still eventually sees a consistent cart, typically within a small replication delay.

13.3 CI/CD & canary deployments

Given how central correctness is to a cart system (a bug here directly costs revenue), changes to the Cart Service and Conflict Resolution Service are rolled out via canary deployment — a small percentage of traffic first, with close monitoring of conflict rate and error rate, before a full rollout.

13.4 Cost optimization

Because WebSocket connections consume server resources even while completely idle (an open connection with no traffic still holds memory and a file descriptor), cost management for this system looks somewhat different from a typical stateless service:

• Idle connection timeouts: Connections that have been idle beyond a reasonable window (e.g., a laptop tab left open and unattended for many hours) are proactively closed, with the client expected to reconnect automatically the next time the tab becomes active, freeing up server resources without materially affecting perceived responsiveness.
• Right-sizing DynamoDB capacity: On-demand or auto-scaled capacity modes track actual cart traffic patterns rather than provisioning fixed capacity for worst-case load, which for a typically spiky retail traffic pattern (daytime peaks, overnight lulls, seasonal surges) avoids paying for unused capacity most of the time.
• Batching non-urgent downstream work: Abandoned-cart detection and analytics consumption from Kafka are processed in efficient batches on a schedule, rather than triggering expensive per-event processing that would scale linearly and unnecessarily with cart traffic.

14.1 Choosing the right database for each job

14.2 Load balancing strategies

REST traffic uses standard least-connections load balancing across API Gateway nodes. WebSocket traffic requires sticky (session-affinity) routing — once a connection is established with a specific WebSocket Gateway node, subsequent traffic for that same connection must continue routing to that same node, since the connection itself is stateful and lives on that node’s memory.

14.3 Cache invalidation strategy

• Hot cart cache (Redis): Write-through — updated immediately on every write, with a moderate TTL as a safety net in case of missed invalidation.
• Connection registry (Redis): Updated on connect/disconnect events directly from the WebSocket Gateway, with a short TTL as a safety net against stale entries from ungracefully terminated connections (e.g., an app crash that doesn’t send a clean disconnect).
• Product catalog cache: Time-based invalidation, since price and stock changes need to propagate reasonably quickly but don’t require the sub-second freshness that cart state itself does.

14.4 Sharding & partitioning

DynamoDB partitions cart records by a hash of the user ID, which spreads write load evenly across the underlying storage nodes regardless of any one user’s activity level. This avoids the classic hot-partition problem where one especially active user (or one popular shared cart) could otherwise concentrate load on a single shard. The Cassandra event log is partitioned by (userId, day), keeping any single user’s recent history on one partition for efficient replay while spreading total load across the cluster over time. The Redis hot cache uses consistent hashing so an individual node addition or removal only reshuffles a small fraction of keys, avoiding the cache stampede that would follow a full re-hash.

15.1 Public API contract

POST /v1/cart/items
  Request:  { itemId, quantityDelta, expectedVersion, idempotencyKey }
  Response: { cart: {...}, version, status: "OK" | "CONFLICT" }

DELETE /v1/cart/items/{itemId}
  Request:  { expectedVersion, idempotencyKey }
  Response: { cart: {...}, version }

GET /v1/cart
  Response: { items: [...], version, lastModified, lastModifiedDevice }

WebSocket message (server to client, pushed):
  {
    type: "CART_UPDATED",
    cart: { items: [...], version },
    changedBy: "deviceId-mobile-XYZ"
  }

WebSocket message (server to client, on reconnect):
  {
    type: "FULL_SYNC",
    cart: { items: [...], version }
  }

Notice the changedBy field on the push message — this lets a client optionally suppress a redundant UI animation on the very device that made the original change (since it already updated itself optimistically), while still fully updating any other connected device.

15.2 Why microservices instead of a monolith here

The Cart Service, Conflict Resolution Service, Fan-out Service, and Pricing & Inventory Service have distinct scaling and reliability profiles — Fan-out and the WebSocket layer scale with connection count, Cart Service scales with write volume, and Pricing & Inventory Service is largely read-heavy against a separate, slower-changing catalog. Splitting them allows each to be scaled, deployed, and evolved independently, and allows a spike in WebSocket connection churn to be isolated from cart-write throughput concerns.

15.3 Internal service-to-service communication

Between internal services, the design uses gRPC over HTTP/2 rather than REST/JSON. The strongly-typed protobuf contracts catch schema mismatches at compile time rather than in production, and gRPC’s binary encoding plus HTTP/2 multiplexing meaningfully reduces both latency and payload size on the fan-out path, where the Cart Service and the Fan-out Service exchange messages hundreds of times per second during peak. External APIs, exposed to browsers and mobile clients, remain REST/JSON for the usual reasons: universal client support, ease of debugging, and cache-friendliness at the edge.

16.1 Patterns used in this design

16.2 Anti-patterns to avoid

17.1 Best practices

• Always write durably before acknowledging success: Never tell a client a cart change succeeded until it’s confirmed in the durable store.
• Use idempotency keys on every mutation: Makes client-side retry logic safe by design, rather than something that has to be carefully avoided.
• Re-validate price and stock at checkout, always: Never trust cached or stale pricing at the moment money changes hands.
• Explicit full-resync on reconnect: Don’t assume incremental push messages are sufficient after any connection gap.
• Favor not losing data in merge logic: When in doubt during conflict resolution, prefer preserving both devices’ intended changes over silently picking one.
• Monitor sync latency as a first-class metric: It’s the most direct measurement of whether the system is delivering on its core promise.

17.2 Common mistakes

• Polling as the only sync mechanism: Leads to a noticeable, unsatisfying delay that undermines the “instant” cross-device experience users now expect.
• No handling for offline queuing: A mobile client that simply fails silently when offline, rather than queuing and replaying, loses user trust the first time it happens.
• Ignoring WebSocket connection churn in capacity planning: Treating the WebSocket Gateway like a stateless REST service in capacity planning underestimates the very different resource profile of holding open connections.
• Skipping synthetic end-to-end sync monitoring: Relying only on infrastructure-level metrics (CPU, error rate) can miss a subtle bug where sync silently stops working for a subset of users while every individual service still reports healthy.

17.3 A practical rollout approach

Teams building this system for the first time are generally well served by a staged approach rather than attempting to ship every piece described in this guide at once:

18.1 A shared underlying pattern

Despite very different product surfaces — a fixed-price retail catalog, an auction marketplace, a merchant-hosted storefront — these platforms converge on a remarkably similar underlying architecture: a durable, versioned, account-tied cart as the single source of truth; a fast cache in front of it for the overwhelming majority of read traffic; some form of push-based propagation to currently active sessions; and notably stricter, more consistency-favoring rules specifically at the moment of checkout, where the cost of getting it wrong is highest. This convergence isn’t a coincidence — it reflects the same fundamental trade-offs discussed throughout this guide, arrived at independently by teams solving the same underlying distributed systems problem.

Depending on the merge policy chosen, most systems either sum the quantities (treating it as the user wanting more of that item) or take the higher of the two resulting quantities — the key design principle is that neither addition should be silently discarded.

Generally no, or only in a very limited form. Cross-device sync fundamentally requires a stable identity to tie the cart to; a guest cart is typically bound to a single device/browser session, and the platform usually offers to merge a guest cart into the account cart at the moment the user logs in or signs up.

Polling technically achieves eventual synchronization too, but with a much coarser and less pleasant user experience — either frequent polling wastes resources and battery, or infrequent polling introduces a noticeable, often multi-second-to-minutes delay. Push-based sync via WebSockets achieves the same end goal with far lower latency and less wasted network traffic.

The Fan-out Service pushes updates to every currently connected device, without a hard limit in principle, though most platforms track and can display “active sessions” and may apply reasonable practical limits on simultaneous connections per account for cost and abuse-prevention reasons.

Largely yes — a wishlist has very similar cross-device sync requirements, though typically with lower urgency around real-time propagation and price/stock re-validation, since a wishlist item isn’t about to be purchased in the next few seconds the way a cart item might be. Many platforms reuse the same underlying sync infrastructure for both, with slightly relaxed latency and validation requirements for the wishlist case.

Through deterministic unit tests that simulate specific conflict scenarios directly (two devices adding different items offline, two devices changing the same item’s quantity within the same second, a removal racing an addition) rather than relying purely on real-world usage to surface these cases, since genuine simultaneous multi-device conflicts can be rare enough in ad-hoc manual testing to hide bugs that only appear at scale in production.

That’s a related but distinct problem — a shared cart across multiple distinct user identities (not just multiple devices of one user) adds additional considerations around permissions and attribution (who added what), but the same core sync and conflict-resolution primitives described in this guide extend naturally to that case, typically by keying the connection registry and fan-out logic on the shared cart ID rather than a single user ID.

Most production systems target roughly one to two seconds end to end for the common case of two actively connected devices on reasonable network conditions, treating this as a strong goal rather than a hard guarantee — occasional outliers driven by network conditions on the receiving device are expected and acceptable, as long as they remain rare and the system reliably catches up on reconnect. Chasing sub-100-millisecond sync for a shopping cart specifically is rarely worth the added complexity, since the user experience benefit beyond roughly one second is minimal for this particular use case, unlike, say, a competitive multiplayer game where every millisecond matters.

A real-time, cross-device shopping cart is fundamentally a distributed state synchronization problem wearing a familiar, everyday disguise. The architecture in this guide combines a durable, versioned source of truth (DynamoDB), a fast cache for the common read path (Redis), a persistent push mechanism for instant propagation (WebSockets, fanned out to every connected device), and a deliberate, product-aware conflict resolution strategy that favors never silently losing something a user intended to buy — all wrapped behind a load balancer and API/WebSocket gateways, with careful re-validation of price and stock at the moments that matter most.

What makes this problem genuinely interesting from a systems design perspective is how it forces two normally opposing priorities to coexist within a single product: the system spends most of its time favoring availability and low latency over strict correctness, precisely because a shopper browsing casually should never be blocked by synchronization concerns, and then deliberately flips that priority the instant checkout begins, favoring strict consistency because that is the one moment where getting it wrong costs real money and real trust.