Imagine a shopping channel from the 1990s — a presenter holding up a blender, talking about it, and a phone number scrolling at the bottom of the screen for viewers to call and order. That idea, home shopping television, is decades old. What is new is what happens when you take that same idea and rebuild it on top of the internet, mobile phones, and modern distributed systems. Instead of a phone call, a viewer taps a screen. Instead of one broadcast reaching a few million TV sets, a stream can reach millions of phones anywhere in the world. And instead of a warehouse worker manually tracking how many blenders are left, a computer system has to know the exact stock count, update it in real time, and never let two people buy the last unit at the same time.

This combination — live video plus e-commerce plus real-time inventory — is usually called live shopping or live commerce. A creator or brand goes live on camera, shows off products, answers questions from viewers in a chat window, and viewers can buy those products without ever leaving the stream. The stream, the chat, the product catalog, and the checkout system all have to work together, in real time, at large scale.

Live commerce did not start in Silicon Valley. It became massive first in China, where platforms such as Taobao Live (part of Alibaba) turned livestream selling into a business worth many billions of dollars a year, with some individual streamers selling more merchandise in a single evening than a mid-size retail chain sells in a month. Seeing that success, western platforms followed: Amazon Live let sellers and influencers demonstrate products on video next to a live “buy” button; TikTok built TikTok Shop directly into its short-video and live-streaming app; Instagram and Facebook experimented with shopping tags inside live video; and newer, focused platforms like Whatnot built their entire business around live auctions and live selling for collectibles, fashion, and hobbyist communities.

From a systems point of view, live shopping is a fascinating problem because it forces three very different engineering worlds to work together at the same time:

In this tutorial we will design such a platform from scratch, piece by piece. We will cover the video pipeline, the microservices that manage products and orders, the message queue that connects everything, the caching layer that makes inventory checks fast, the database design that keeps orders and stock counts correct, and the operational concerns — security, monitoring, deployment — that keep the whole system running smoothly during a launch event that might attract a huge, sudden spike of traffic in the space of a few minutes.

Before drawing any boxes and arrows, we need to be precise about what problem we are actually solving, and why it is hard. It is easy to say “let creators sell products on a livestream.” It is much harder to say exactly what breaks if we build this carelessly.

2.1 What makes this different from normal e-commerce?

A normal online store, like a typical product listing page, has a fairly gentle traffic pattern. People browse whenever they want, over hours or days. A live shopping event compresses all of that demand into a very short, very intense window — often just a few minutes — because the creator says on camera, “I have only 200 units of this jacket, link is live now,” and thousands of viewers, all watching the same video at the same moment, react at the same moment.

2.2 The core hard problems

2.3 Business motivation

Beyond the technical challenge, the business case is strong: live shopping combines entertainment and commerce (“shoppertainment”), which tends to produce far higher conversion rates than static product pages, because viewers get real-time answers to their questions, social proof from other viewers buying at the same time, and a sense of urgency from limited stock and a ticking clock. Getting the system right directly translates into revenue; getting it wrong — a stream that lags, a checkout that fails, or a stock count that is wrong — directly damages trust and sales in a very visible, very public way, in front of a live audience.

3.1 Functional Requirements

3.2 Non-Functional Requirements

3.3 Back-of-the-envelope scale estimation

Let’s reason about scale, since it drives almost every later decision:

These numbers tell us immediately that we cannot rely on a single database instance for inventory, we cannot broadcast chat by looping over a list of users in application code, and we cannot serve video by streaming directly from the creator’s device to every viewer — we need a CDN.

Let’s now design the system piece by piece. We will split it into three cooperating “planes”: the video plane (getting the creator’s camera feed to millions of viewers), the commerce plane (product catalog, inventory, orders, payments), and the real-time engagement plane (chat, reactions, live viewer counts). All three sit behind a shared edge layer of load balancers, API gateway, and CDN.

4.1 High-Level Architecture Diagram

Every box below is labeled with exactly what kind of component it is, so the role of each piece in the request path is unambiguous.

At first glance this looks like a lot of boxes, but each one exists to solve exactly one of the hard problems from Section 2. Let’s walk through every component, what it is, why it exists, and how it maps to something familiar.

4.2 Edge Layer

4.2.1 CDN (Content Delivery Network)

What it is: A globally distributed network of edge servers that cache and serve content physically close to each viewer.

Why it exists: Video is heavy. If every viewer pulled video directly from our origin servers, our data center’s network link would be overwhelmed in seconds by a stream with a million viewers. A CDN instead lets each viewer download video segments from a nearby edge node, so our origin only needs to serve a handful of edge nodes, not millions of viewers directly.

In this system: The CDN caches the video’s HLS/DASH segments and also serves static assets like product images. Popular CDNs used for this include Akamai, Cloudflare, Amazon CloudFront, and Fastly.

4.2.2 Load Balancer (Layer 7)

What it is: A component that sits in front of a group of servers and distributes incoming requests across them, using application-level information (HTTP path, headers) since we labeled it Layer 7.

Why it exists: No single server can handle millions of requests. The load balancer spreads traffic evenly, performs health checks to route around failed instances, and terminates TLS so backend services don’t each need to manage certificates.

In this system: NGINX or Envoy sit at the edge, terminating TLS and load-balancing across API Gateway instances. During a flash-sale spike, the load balancer’s health checks and connection-draining logic keep failing instances out of rotation immediately.

4.2.3 API Gateway

What it is: A single, unified entry point for all client requests into the backend microservices.

Why it exists: Without a gateway, every client would need to know the address of every individual microservice, and every microservice would need to reimplement authentication, rate limiting, and request logging. The gateway centralizes these cross-cutting concerns.

In this system: The API Gateway authenticates the viewer’s session token, applies per-user and per-IP rate limiting (critical during a “buy now” surge to stop bots and retries from overwhelming the Order Service), and routes /catalog/* to the Catalog Service, /inventory/* to the Inventory Service, /orders/* to the Order Service, and upgrades /chat connections to WebSocket and routes them to the Chat Service.

4.3 Video Plane Components

4.3.1 Stream Ingest Service

What it is: The entry point that receives the live video/audio feed from the creator’s camera or streaming software, typically over the RTMP or WebRTC protocol.

Why it exists: The creator’s raw camera feed needs a dedicated, always-available receiving endpoint that can handle unreliable mobile networks, reconnect gracefully, and hand the stream off for processing.

Production example: Twitch and YouTube Live use dedicated ingest server fleets distributed by geography so a creator connects to a nearby ingest point, minimizing upload latency before transcoding even starts.

4.3.2 Transcoding Service

What it is: Converts the single incoming high-bitrate stream into multiple quality “renditions” (for example 1080p, 720p, 480p, 240p).

Why it exists: Viewers have wildly different network conditions — a viewer on fast Wi-Fi and a viewer on patchy mobile data cannot both be served the exact same video bitrate. Transcoding produces several versions so the player on each device can pick (and dynamically switch) the best one, a technique called adaptive bitrate streaming (ABR).

4.3.3 Packaging Service

What it is: Slices each transcoded rendition into small segments (typically 2–6 seconds) and produces a manifest file, packaged as HLS (HTTP Live Streaming) or DASH (Dynamic Adaptive Streaming over HTTP).

Why it exists: Video players can’t efficiently stream one giant continuous file over HTTP. Breaking video into small segments lets players fetch, cache, and switch quality level segment-by-segment, and lets the CDN cache each small segment independently.

4.4 Commerce Plane Components

4.4.1 Product Catalog Service

What it is: Owns product data — titles, descriptions, images, prices, variants (size/color) — and serves fast reads to the client and to other services.

Why it exists: Product data changes rarely compared to inventory, and is read constantly (every viewer loads product cards). Separating it from inventory lets us cache it aggressively without worrying about staleness on the number that actually matters for correctness (stock count).

4.4.2 Inventory Service

What it is: The single source of truth for how many units of each product/variant are available, and the component responsible for atomically reserving and decrementing stock as orders are placed.

Why it exists: This is the most safety-critical service in the whole system. It exists as an isolated service (rather than a field on the Catalog Service) specifically so it can be optimized, scaled, and locked down for one job: never letting stock go negative, no matter how much concurrent load hits it.

We will look at exactly how it achieves atomic decrements under extreme concurrency in Section 5.

4.4.3 Order Service

What it is: Manages the lifecycle of an order — created, payment pending, paid, fulfilled, cancelled, refunded — and orchestrates the multi-step process of turning a “Buy” click into a confirmed purchase.

Why it exists: A purchase touches multiple systems (inventory, payment, shipping). The Order Service coordinates these steps as a single logical transaction using patterns like Saga (explained in Section 15), so that a failure partway through — for example, a payment decline after inventory was reserved — is always cleanly rolled back.

4.4.4 Payment Service

What it is: Handles charging the customer’s payment method, typically by calling out to a PCI-compliant third-party payment processor (Stripe, Razorpay, Adyen, PayPal) rather than handling raw card data itself.

Why it exists: Isolating payment logic into one service shrinks the “PCI compliance boundary” — the part of the system that must meet strict card-data security standards — to the smallest possible surface area, instead of spreading sensitive payment handling across the whole codebase.

4.4.5 Shipping / Fulfillment Service

What it is: Triggered after a successful payment, this service creates fulfillment tasks — packing, warehouse pick lists, courier handoff, tracking numbers.

Why it exists: Fulfillment is inherently asynchronous (a warehouse worker packs a box over minutes or hours, not milliseconds) so it is decoupled from the fast, synchronous checkout path via the message broker.

4.5 Real-Time Engagement Plane

4.5.1 Chat Service (WebSocket Gateway)

What it is: Manages persistent WebSocket connections with every connected viewer, receiving chat messages and reactions and fanning them out to all other viewers of that stream.

Why it exists: HTTP request/response is the wrong model for “many people need to see the same message within milliseconds.” WebSockets keep an open, bidirectional connection so the server can push messages instantly instead of clients repeatedly polling.

Scaling note: Chat servers are typically organized so all connections for a given stream’s “room” are grouped, and a pub/sub layer (Redis Pub/Sub or a Kafka topic per popular room) fans messages out across many chat server instances, since a single server cannot hold a million concurrent WebSocket connections for one viral stream.

4.5.2 Presence / Viewer-Count Service

What it is: Tracks who is currently watching each stream and produces the “12,458 watching” counter.

Why it exists: An exact, strongly consistent count would require coordinating every single connect/disconnect event, which is unnecessary overhead for a number that is inherently approximate and constantly changing. This service uses approximate counting (for example, periodically aggregated counts from each chat server shard) which is far cheaper and entirely acceptable for this use case.

4.5.3 Notification Service

What it is: Sends push notifications, SMS, or email — for example, “Your favorite creator just went live,” or “Your order has shipped.”

Why it exists: Like fulfillment, notifications are asynchronous and non-critical-path, so they are triggered by events on the message broker rather than blocking any user-facing request.

4.6 Shared Infrastructure

4.6.1 Message Broker (Kafka)

What it is: A distributed, append-only log system that lets services publish events (like “order placed” or “stock updated”) and lets other services subscribe and react, without the publisher needing to know who is listening.

Why it exists: Without an event bus, every service would need direct point-to-point calls to every other interested service, creating a tangled, fragile web of synchronous dependencies. The broker decouples producers from consumers, absorbs bursts of traffic (acting as a buffer), and lets us add new consumers (like a new analytics pipeline) without touching existing services.

4.6.2 Cache Cluster (Redis)

What it is: An in-memory key-value data store used to hold frequently accessed, latency-sensitive data — hot product info, session tokens, and critically, live inventory counters.

Why it exists: Reading and writing a stock counter from a disk-based relational database, thousands of times per second, is far too slow for a flash-sale moment. Redis keeps the “hot” numbers in memory and supports atomic operations, which we rely on heavily in Section 5.

4.6.3 Observability Stack

What it is: The combination of metrics collection (Prometheus), dashboards (Grafana), distributed tracing (OpenTelemetry/Jaeger), and centralized logging (the ELK stack: Elasticsearch, Logstash, Kibana).

Why it exists: With a dozen microservices cooperating on a single purchase, when something goes wrong you need to trace one request’s full journey across every service it touched — this is covered fully in Section 11.

Now let’s zoom into the two hardest internal mechanics: how a “Buy” click is processed without overselling, and how the video actually gets from a phone camera to a million screens with only a few seconds of delay.

5.1 The Purchase Path, Step by Step

1. Viewer taps “Buy” on the spotlighted product inside the stream player.
2. Request hits the Load Balancer, then the API Gateway, which checks the auth token and applies rate limiting.
3. The Order Service receives the purchase intent and calls the Inventory Service to reserve one unit — not yet a full decrement, but a short-lived hold (see 5.2).
4. If the reservation succeeds, the Order Service creates a pending order record and calls the Payment Service to charge the customer.
5. If payment succeeds, the Order Service confirms the reservation (now a real decrement) and marks the order as paid; it publishes an OrderPlaced event to Kafka.
6. If payment fails, the Order Service releases the reservation back to available stock, and the order is marked failed.
7. Downstream consumers of the OrderPlaced event (Shipping Service, Notification Service, Analytics Warehouse) react independently and asynchronously.
8. The updated stock count is pushed to all viewers of that stream via the Presence/Chat pub-sub channel, so everyone sees “3 left” tick down live.

5.2 Solving the Overselling Problem: Atomic Reservation

The naive approach — “read the stock count, check if it’s greater than zero, then write count-1” — is broken under concurrency. If a thousand requests all read “5” before any of them writes, all thousand may believe they succeeded. This is called a race condition, and it’s exactly what causes overselling.

The fix is to make the check-and-decrement a single, indivisible (atomic) operation, so no two requests can ever interleave their reads and writes. Redis makes this simple with a Lua script, which Redis guarantees runs atomically, from start to finish, with no other command executing in between:

-- KEYS[1] = inventory key, e.g. "inventory:product:12345"
-- Returns: 1 if reserved successfully, 0 if out of stock, -1 if key missing

local stock = tonumber(redis.call('GET', KEYS[1]))
if stock == nil then
    return -1  -- product not found in cache
end
if stock > 0 then
    redis.call('DECR', KEYS[1])
    return 1
else
    return 0
end

Here is how the Inventory Service (written in Java, using the Spring framework and Lettuce/Jedis Redis client) calls this script atomically:

@Service
public class InventoryReservationService {

    private final RedisScript<Long> decrementScript;
    private final StringRedisTemplate redisTemplate;
    private final KafkaTemplate<String, InventoryEvent> kafkaTemplate;

    public InventoryReservationService(StringRedisTemplate redisTemplate,
                                        KafkaTemplate<String, InventoryEvent> kafkaTemplate) {
        this.redisTemplate = redisTemplate;
        this.kafkaTemplate = kafkaTemplate;
        this.decrementScript = RedisScript.of(
            new ClassPathResource("scripts/atomic-decrement.lua"), Long.class);
    }

    public ReservationResult reserve(String productId, String orderId) {
        String key = "inventory:product:" + productId;
        Long result = redisTemplate.execute(decrementScript, List.of(key));

        if (result == null || result == -1L) {
            throw new ProductNotCachedException(productId);
        }
        if (result == 0L) {
            return ReservationResult.OUT_OF_STOCK;
        }

        // Reservation succeeded - record a short-lived hold so we can
        // roll back cleanly if payment fails.
        String holdKey = "hold:" + orderId;
        redisTemplate.opsForValue().set(holdKey, productId, Duration.ofMinutes(2));

        // Publish so live viewers see the count drop.
        kafkaTemplate.send("inventory-events",
            new InventoryEvent(productId, InventoryEventType.RESERVED, orderId));

        return ReservationResult.RESERVED;
    }

    public void release(String orderId) {
        String holdKey = "hold:" + orderId;
        String productId = redisTemplate.opsForValue().get(holdKey);
        if (productId != null) {
            redisTemplate.opsForValue().increment("inventory:product:" + productId);
            redisTemplate.delete(holdKey);
            kafkaTemplate.send("inventory-events",
                new InventoryEvent(productId, InventoryEventType.RELEASED, orderId));
        }
    }
}

Why does this scale so well? Because Redis is single-threaded for command execution on a given key, every DECR-style operation against one key is naturally serialized — there is no possibility of two requests interleaving on the same counter, and no explicit application-level lock is needed at all.

5.3 Keeping Redis and the Database in Sync

Redis gives us speed, but it is a cache, not the ultimate source of truth for financial-grade correctness — a cache node could restart and lose data. So the design uses a two-tier approach:

• Fast path (hot): Redis atomic decrement handles the flash-sale-speed reservation check.
• Durable path (source of truth): The Order Service, once payment succeeds, writes the final, authoritative decrement into the relational database inside the same transaction as the order confirmation, using optimistic locking as a second safety net.

Here’s the JPA entity with optimistic locking as a defense-in-depth safety net, in case Redis and the database ever drift (for example after a cache failover):

@Entity
@Table(name = "inventory")
public class InventoryRecord {

    @Id
    private String productId;

    @Column(nullable = false)
    private int stockCount;

    @Version   // JPA optimistic locking column
    private long version;

    public void decrementStock() {
        if (stockCount <= 0) {
            throw new InsufficientStockException(productId);
        }
        this.stockCount -= 1;
    }
    // getters/setters omitted
}

@Service
public class InventoryPersistenceService {

    @Retryable(value = OptimisticLockException.class, maxAttempts = 5,
               backoff = @Backoff(delay = 20, multiplier = 2))
    @Transactional
    public void confirmDecrement(String productId) {
        InventoryRecord record = inventoryRepository.findById(productId)
            .orElseThrow(() -> new ProductNotFoundException(productId));
        record.decrementStock();
        inventoryRepository.save(record); // throws OptimisticLockException on version conflict
    }
}

If two transactions somehow race at the database layer, JPA’s @Version column causes the losing transaction’s commit to fail with an OptimisticLockException, which we retry with exponential backoff. In practice, because Redis already serialized the reservation upstream, this database-level conflict should be rare — it exists purely as a correctness backstop, not the primary defense.

5.4 The Video Path: Glass-to-Glass

“Glass-to-glass latency” means the time from light hitting the creator’s camera lens to light leaving the viewer’s screen. Here is that path:

Two techniques keep this fast: using small segment sizes (so the player doesn’t wait for a large chunk to finish encoding before it can start playing), and using WebRTC instead of RTMP for the sub-second-latency “interactive” tier some platforms offer for creator-to-moderator communication, while the bulk of viewers still consume the slightly higher-latency but far more scalable HLS/DASH path through the CDN.

Let’s trace one complete “life of a purchase” as a sequence diagram, showing every component from Section 4 working together.

6.1 The Rollback Path (Payment Failure)

Correctness also requires handling the unhappy path cleanly. If payment fails after inventory was reserved, we must release the hold immediately so the unit becomes available to the next viewer:

Note that the two-minute hold TTL set on the Redis key in Section 5.2 acts as a safety net too: even if the Order Service crashes mid-flow and never explicitly calls release(), the hold key expiring automatically frees the reservation, and a background reconciliation job re-adds the unit to the visible stock count if it detects an orphaned hold.

6.2 Product Lifecycle During a Live Event

7.1 Advantages of This Architecture

7.2 Disadvantages and Costs

7.3 Key Trade-off Decisions

8.1 Scaling the Video Path

8.2 Scaling the Checkout Path

8.3 Scaling Chat and Presence

9.1 Redundancy at Every Layer

9.2 Resilience Patterns in Application Code

Even with redundant infrastructure, individual calls between services can still fail or time out. We use the circuit breaker pattern to prevent one failing dependency from cascading into a full outage:

@Service
public class PaymentClient {

    private final CircuitBreaker circuitBreaker;
    private final RestClient restClient;

    public PaymentClient(CircuitBreakerRegistry registry, RestClient restClient) {
        this.circuitBreaker = registry.circuitBreaker("payment-service");
        this.restClient = restClient;
    }

    public PaymentResult charge(ChargeRequest request) {
        Supplier<PaymentResult> call = CircuitBreaker
            .decorateSupplier(circuitBreaker, () ->
                restClient.post()
                    .uri("/v1/charges")
                    .body(request)
                    .retrieve()
                    .body(PaymentResult.class));

        try {
            return call.get();
        } catch (CallNotPermittedException e) {
            // Circuit is open - payment provider is unhealthy.
            // Fail fast instead of piling up timeouts.
            return PaymentResult.temporarilyUnavailable();
        }
    }
}

Configured with Resilience4j, this circuit breaker trips (“opens”) after a threshold of failures within a rolling window, immediately rejecting further calls to the failing payment provider for a cooldown period rather than letting every checkout request pile up waiting on a doomed call. This keeps the rest of the system responsive and gives the failing dependency room to recover.

9.3 Disaster Recovery

9.4 Graceful Degradation

Not every failure needs to become a full outage. The system is designed so lower-priority features degrade first, protecting the core “watch and buy” path:

• If the Chat Service is overloaded, chat can be temporarily throttled or paused while video and checkout continue uninterrupted.
• If the recommendation/personalization service is down, viewers still see the default product lineup instead of a broken page.
• If analytics ingestion (Kafka to the warehouse) lags, dashboards show slightly stale numbers, but no customer-facing functionality is affected.

10.1 Authentication and Authorization

• OAuth2 / OpenID Connect for viewer and creator login, issuing short-lived JWT access tokens plus longer-lived refresh tokens.
• API Gateway as the enforcement point: every request’s JWT is validated at the gateway before it ever reaches a backend microservice, so individual services can trust the identity context passed to them rather than each re-implementing token validation.
• Role-based access control (RBAC): distinguishes viewer, creator, moderator, and platform-admin permissions — for example, only a creator or moderator for a given stream can remove chat messages or ban a user in that room.

10.2 Payment and PCI-DSS

Raw card numbers never touch our own servers. The client-side SDK (e.g., Stripe.js/Elements) tokenizes card details directly with the payment processor in the browser or app, and our Payment Service only ever handles that opaque token, never the underlying card number. This keeps almost the entire platform out of PCI-DSS’s strictest compliance scope (SAQ A rather than the far more demanding SAQ D).

10.3 Protecting the Flash-Sale Moment from Abuse

10.4 Content and Chat Moderation

• Automated profanity/spam/hate-speech filtering on chat messages before broadcast, backed by a moderation ML model or third-party moderation API.
• Creator/moderator tools to mute, ban, or slow-mode chat during a stream.
• Video content moderation (automated flagging for policy violations) for creators, especially relevant for platforms open to a wide range of independent sellers.

10.5 Data Protection

• Encryption in transit (TLS everywhere, including between internal services in stricter deployments — mTLS) and encryption at rest for databases holding personal and payment-related data.
• Field-level encryption or tokenization for sensitive personally identifiable information (shipping addresses, phone numbers).
• Strict data retention and deletion policies to comply with privacy regulations (such as GDPR in Europe or India’s DPDP Act), including honoring user data-deletion requests across every service that stores their data.

11.1 What We Must Watch During a Live Event

11.2 Distributed Tracing

A single purchase touches the Gateway, Order, Inventory, Payment, and database — tracing that whole journey with one shared trace ID is essential for debugging. Using OpenTelemetry, every service propagates trace context automatically:

@RestController
public class OrderController {

    private static final Tracer tracer =
        GlobalOpenTelemetry.getTracer("order-service");

    @PostMapping("/orders")
    public ResponseEntity<OrderResponse> createOrder(@RequestBody OrderRequest req) {
        Span span = tracer.spanBuilder("createOrder")
            .setAttribute("product.id", req.getProductId())
            .setAttribute("user.id", req.getUserId())
            .startSpan();

        try (Scope scope = span.makeCurrent()) {
            ReservationResult reservation = inventoryClient.reserve(req);
            span.setAttribute("reservation.result", reservation.name());

            if (reservation != ReservationResult.RESERVED) {
                span.setStatus(StatusCode.ERROR, "out_of_stock");
                return ResponseEntity.status(409).body(OrderResponse.outOfStock());
            }

            PaymentResult payment = paymentClient.charge(req);
            span.setAttribute("payment.result", payment.name());
            // ... persist order, publish event ...
            return ResponseEntity.ok(OrderResponse.from(payment));
        } finally {
            span.end();
        }
    }
}

With this in place, when a customer reports “my buy button spun forever,” an engineer can pull up the exact trace for that request ID and see precisely which service or downstream call was slow — the Inventory reservation, the Payment provider, or the database write — instead of guessing.

11.3 Alerting Philosophy

• Alert on symptoms that affect customers (checkout latency, error rate, video buffering) rather than only on low-level infrastructure metrics (CPU, memory) that don’t necessarily indicate customer impact.
• Use multi-window, multi-burn-rate alerting (based on Google’s SRE practices) so a brief blip doesn’t page an engineer at 2 a.m., but a sustained problem during a live event pages immediately.
• Maintain a real-time “event health” dashboard specifically for the duration of a scheduled major live shopping event, watched actively by an on-call team, since these events are pre-planned and high-stakes.

12.1 Container Orchestration

All stateless microservices (Order, Inventory, Catalog, Chat, Payment client, Notification) are packaged as containers and run on Kubernetes, which handles scheduling, health checking, and automatic restarts. Kubernetes’ Horizontal Pod Autoscaler (HPA) scales each service’s replica count based on real-time CPU, memory, or custom metrics (like queue depth or requests-per-second) — critical for handling the sudden spike when a live event begins.

# Simplified HPA config for the Order Service
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: order-service-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: order-service
  minReplicas: 10
  maxReplicas: 500
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 60
    - type: Pods
      pods:
        metric:
          name: http_requests_per_second
        target:
          type: AverageValue
          averageValue: "200"
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 0
      policies:
        - type: Percent
          value: 200
          periodSeconds: 30

Note the aggressive scale-up policy (doubling capacity every 30 seconds with no stabilization delay) — appropriate here because live shopping traffic spikes are sudden and predictable in timing (the event has a scheduled start), so we would rather over-provision briefly than fall behind demand in the first critical seconds.

12.2 Pre-Warming for Scheduled Events

Because major live shopping events are scheduled in advance (unlike organic traffic spikes), the platform can proactively scale up capacity minutes before the event starts, rather than relying solely on reactive autoscaling that might not react fast enough for the first wave of a synchronized spike. This is a significant operational advantage live shopping has over unpredictable viral traffic.

12.3 Multi-Region Cloud Topology

• Video ingest and CDN: distributed globally by design (this is standard practice for any major cloud/CDN provider).
• Commerce services: deployed in multiple regions, with the Order DB primary in one region and read replicas in others, routing writes to the primary region and reads to the nearest replica.
• Data residency: for platforms operating across regulatory boundaries (e.g., needing to keep Indian users’ data within India under local data protection rules), region-pinned deployments and data stores keep specific customer data within required jurisdictions.

12.4 Progressive Delivery

New versions of services are rolled out using canary deployments — a new version first receives a small percentage (say 5%) of production traffic, monitored closely for error-rate or latency regressions, before gradually increasing to 100%, with automatic rollback if the canary’s metrics degrade. This is especially important for the Inventory and Order services, where a subtle bug could cause real financial and customer-trust damage if rolled out to 100% of traffic immediately — and deployments are typically frozen entirely during scheduled major live events as an extra safety measure.

13.1 Choosing the Right Database for Each Job

13.2 Sharding the Order Database

The Order DB is sharded by a key such as user_id or region, so that no single database instance needs to handle the entire platform’s order volume. Each shard is a fully independent PostgreSQL primary/replica pair. A lightweight routing layer in the Order Service determines which shard owns a given order based on the shard key, consistent with typical horizontal partitioning strategy used across large-scale e-commerce systems.

13.3 Caching Strategy

• Cache-aside for product data: the Catalog Service checks Redis first; on a miss, it reads from MongoDB and populates the cache, with a time-to-live (TTL) to bound staleness.
• Write-through for inventory: unlike product data, inventory writes go to Redis first (for the fast atomic check), then asynchronously reconciled to the database, as described in Section 5.3 — a deliberate exception to the usual cache-aside pattern because raw speed on the write path is the priority here.
• Cache invalidation on product update: when a creator edits a product’s price or description mid-stream, the Catalog Service publishes an invalidation event so all cache nodes drop the stale entry rather than waiting out the TTL.

13.4 Load Balancing Deep Dive

13.5 Consistent Hashing for Cache and Chat Sharding

Both the Redis cluster (for inventory keys) and the Chat Service’s room assignment rely on consistent hashing to distribute keys/rooms across nodes. Consistent hashing ensures that when a node is added or removed (scaling up for an event, or recovering from a failure), only a small fraction of keys need to move to a new node, rather than reshuffling almost everything — which would happen with naive modulo-based hashing.

14.1 Choosing Protocols per Use Case

14.2 Example REST Contract: Reserve and Purchase

POST /api/v1/orders
Headers: Authorization: Bearer <jwt>, Idempotency-Key: <uuid>
Body:
{
  "productId": "prod_98213",
  "streamId": "stream_44210",
  "quantity": 1,
  "paymentMethodToken": "tok_abc123"
}

Response 200 OK:
{
  "orderId": "ord_77123",
  "status": "PAID",
  "amount": 2499,
  "currency": "INR"
}

Response 409 Conflict:
{
  "error": "OUT_OF_STOCK",
  "message": "This item just sold out."
}

14.3 Example gRPC Contract: Inventory Service

syntax = "proto3";

service InventoryService {
  rpc Reserve (ReserveRequest) returns (ReserveResponse);
  rpc Release (ReleaseRequest) returns (ReleaseResponse);
  rpc GetStock (StockRequest) returns (stream StockUpdate); // server-streaming for live counts
}

message ReserveRequest {
  string product_id = 1;
  string order_id = 2;
}

message ReserveResponse {
  bool reserved = 1;
  int32 remaining_stock = 2;
}

The GetStock RPC uses gRPC’s server-streaming capability — a single call keeps a stream open and the server pushes new stock values as they change, which is how internal dashboard services and the Presence Service can get live inventory updates without polling.

14.4 Microservice Boundaries: Why Split It This Way?

Service boundaries in this design follow the principle of splitting along independent scaling needs and independent rates of change, not just “one service per database table.” Catalog changes rarely and is read-heavy; Inventory changes constantly and must be extremely fast and safe; Payment has unique compliance requirements; Chat has entirely different connection-lifecycle characteristics (long-lived WebSocket state) than the mostly-stateless REST services. Each boundary reflects a genuinely different operational profile, which is the right reason to draw a service line — splitting services just for the sake of “microservices” without a clear independent-scaling or independent-ownership reason tends to just add complexity without benefit.

15.1 The Saga Pattern (Distributed Transactions)

A purchase spans three services (Inventory, Payment, Order) with no shared database transaction across them. The Saga pattern handles this by breaking the operation into a sequence of local transactions, each with a defined compensating action if a later step fails.

We use an orchestration-based saga, where the Order Service explicitly plays the role of orchestrator, calling each step in order and triggering compensations on failure — this is easier to reason about and debug than a choreography-based saga (where each service reacts to the previous service’s event with no central coordinator), which tends to work better for longer, more loosely-coupled workflows like post-payment fulfillment.

15.2 CQRS (Command Query Responsibility Segregation)

The Inventory Service’s write path (atomic Redis decrement) and read path (serving “N left” to millions of viewers) have very different requirements — writes need strict correctness and low contention, reads need to scale to enormous fan-out. CQRS separates these: writes go through the tightly controlled reservation path, while the “current stock” number shown to viewers is served from a separately scaled, cached read model that is updated via the Kafka InventoryUpdated event stream, rather than every viewer’s screen hitting the authoritative counter directly.

15.3 Event Sourcing for Inventory Auditability

Rather than only storing the current stock count, the Inventory Service also appends every reservation, confirmation, and release as an immutable event to Kafka. This gives a complete, replayable audit trail — essential for resolving disputes (“why does the count not match what I expected?”) and for reconstructing state if a bug ever requires rebuilding the cache from scratch.

15.4 Anti-Patterns to Avoid

16.1 Best Practices

16.2 Common Mistakes

Live shopping is not a hypothetical exercise — it is a large and fast-growing part of e-commerce today. A few real platforms illustrate different points on the design spectrum we’ve discussed:

Designing a live shopping platform means designing three systems that must feel like one seamless experience to the viewer: a low-latency video pipeline, a rock-solid real-time inventory and checkout system, and a highly scalable social/chat layer. The single hardest and most important problem is preventing overselling under extreme, synchronized concurrency, solved here with atomic operations in an in-memory cache, backed by durable, optimistically-locked persistence in a relational database as a safety net.