Design an E-Commerce Analytics Dashboard

Problem statement

Design an analytics dashboard platform for an e-commerce marketplace where internal operators (category managers, marketing, finance) and external merchants see real-time or near-real-time statistics: revenue and GMV, orders per minute, conversion funnels, top-selling products and categories, abandoned carts, and regional breakdowns. Users filter by date range, region, category, channel, and merchant, drill down from a global KPI tile to a product-level table, and trust the numbers enough to make inventory and spend decisions.

This is not "put a chart on top of the orders database". A marketplace runs tens of thousands of behavioral events per second, hundreds of thousands of orders per day, and thousands of concurrent dashboard users who each expect a different slice of the same facts, at different freshness, under different permissions. The merchant who sells kitchen goods must never see the fashion seller's revenue, the finance team must see numbers that reconcile with the ledger to the cent, and the marketing analyst must be able to drill from "conversion dropped 8% today" to the exact funnel step and region in under two seconds.

What makes this problem distinctive

Three tensions define the architecture. First, freshness versus cost: sub-minute revenue requires a streaming path, but streaming everything to an interactive store is expensive, so the design needs explicit freshness tiers with different engines and budgets. Second, correctness versus latency: revenue is money, so every aggregate must be deduplicated, reconcilable, and traceable back to source order events; an approximately-right revenue number that disagrees with finance is worse than no number. Third, multi-tenancy versus performance: 300,000 merchant-facing dashboards share infrastructure with internal power users running wide ad-hoc scans, and one tenant's heavy query must not starve another tenant's checkout-KPI tile.

Public evidence shows the category operates at real scale. Shopify's BFCM 2023 summary reports $9.3B in sales across the weekend and a peak of 4.2 million checkouts per minute, and Amazon announced that Prime Day 2023 moved more than 375 million items in two days while Adobe Analytics estimated $12.7B in global online sales. Those are cited company and analyst figures, not requirements for our fictional system.

For capacity planning this answer assumes a mature marketplace with 60 million MAU, 12 million DAU, 300,000 active merchants, 600,000 orders per day average, 2.6 billion analytics-relevant events per day, and a 5x holiday peak. Unless tied to a citation, every number is an explicit design assumption, target, or budget.

The four architectural planes

1. Ingestion plane: SDKs, service outboxes, and connectors that capture order, clickstream, and marketing events with schemas, identities, and sequence numbers.
2. Processing plane: stream jobs and batch jobs that clean, deduplicate, join to dimensions, and pre-aggregate facts into freshness tiers.
3. Serving plane: a hot OLAP store for sub-second KPI tiles, a warm lakehouse for deep drill-down, caches, and a query API with cost governance.
4. Experience and governance plane: dashboard metadata, the semantic metric layer, RBAC and row-level security, auditing, and data-quality monitoring.

A strong interview answer keeps these planes separate. The experience plane may degrade (cached tiles, slightly stale labels) without corrupting the processing plane, and the processing plane may lag without ever serving a number it cannot trace to source events.