Problem Statement: Real-Time Support as a Revenue-Critical E-Commerce Surface
Frames the system as a latency-sensitive, context-rich, multi-actor messaging platform embedded in the commerce funnel — not a standalone chat app.
Problem statement
Design a real-time customer support system for a large e-commerce platform. Customers initiate live chat from the storefront while browsing, at checkout, or after an order issue. Agents receive the conversation in a console enriched with the customer's recent orders, cart contents, browsing session, and account tier. Unresolved issues escalate to tickets. A chatbot handles tier-1 deflection before routing to a human agent.
This is not a generic messaging app. Every second of wait time at checkout correlates with cart abandonment. Zendesk reports that 73% of consumers say a good experience is key to brand loyalty, and Intercom published that median first-response time under 1 minute increases resolution satisfaction by over 20%. The system must therefore treat time-to-first-response as a primary SLO on par with availability.
Why the problem is distinctive
A notification system can tolerate seconds of delay. A support chat during an active checkout cannot. The design must separate session continuity (the conversation must survive agent reassignment, network blips, and page refreshes) from context freshness (the agent must see the latest cart state, not a 10-minute-old snapshot). It must also handle the asymmetry between customer and agent: one customer has one session; one agent handles 3-8 concurrent sessions across tabs, each with independent typing indicators, read receipts, and context panels.
The four architectural planes
- Messaging plane: WebSocket transport, message ordering, delivery guarantees, presence, typing indicators.
- Routing plane: skill-based assignment, queue management, chatbot deflection, escalation to tickets.
- Context plane: order lookup, cart enrichment, browsing history, CRM data, agent visibility scoping.
- Operations plane: agent dashboards, SLA monitoring, quality scoring, capacity planning, compliance.
A strong answer keeps these planes decoupled. The messaging plane must not block on context enrichment. The routing plane must not require a synchronous order-service call before placing a customer in queue. The context plane must degrade gracefully when the order service is slow — the agent sees a loading state, not a blocked session.
Public operating baseline versus design assumptions
Zendesk publicly reports serving over 100,000 customers across 160 countries. Intercom reports powering conversations for 25,000+ businesses. Salesforce Service Cloud reports over 150,000 customers. Amazon handles customer service at a scale where millions of contacts per day span chat, voice, and social channels. These are cited public figures for context.
For capacity planning, this answer explicitly assumes a mature e-commerce platform with 50 million monthly active shoppers, 500,000 concurrent storefront sessions at peak, 120,000 support contacts per day, and a 4x event peak during flash sales. Unless a number is tied to a public citation, it is a stated design assumption.
Key Highlights
- •Time-to-first-response is a revenue-critical SLO, not just a support metric — checkout abandonment correlates with wait time.
- •One agent handles 3-8 concurrent sessions; the system must multiplex context, presence, and message delivery per session.
- •Four planes: messaging, routing, context enrichment, and operations — each with independent failure semantics.
- •Context enrichment must be asynchronous and degrade gracefully; the chat must not block on order-service latency.
- •Assumed scale: 50M monthly shoppers, 500K concurrent sessions, 120K contacts/day, 4x peak multiplier.
Section Rescue Kit
Buzzwords to use:
Safe statements:
- "I will separate messaging transport from context enrichment so the chat never blocks on an order-service call."
- "Before selecting technologies, let me define which plane owns ordering, which owns routing, and which owns context freshness."