PracHub
QuestionsCoachesLearningGuidesInterview Prep
|Home/System Design/Vanta

Design a DAU/MAU metrics system

Last updated: Jun 24, 2026

Quick Overview

A Vanta software-engineer system-design interview question: design a scalable pipeline to compute and serve DAU and MAU engagement metrics for a large consumer app. It tests event ingestion, identity and de-duplication, exact vs. approximate distinct counting (HyperLogLog/bitmaps), handling of time zones and late/out-of-order events, streaming-vs-batch correctness, dashboard serving, and monitoring/privacy.

  • medium
  • Vanta
  • System Design
  • Software Engineer

Design a DAU/MAU metrics system

Company: Vanta

Role: Software Engineer

Category: System Design

Difficulty: medium

Interview Round: Onsite

##### Question Design a system that computes and serves product engagement metrics — **DAU** (Daily Active Users) and **MAU** (Monthly Active Users) — for a large consumer application. An "active user" is a distinct user who performed at least one qualifying event (e.g., app open, page view, login, session start) within the time window. Your design should address: 1. **Metric definitions.** DAU is the number of unique active users per calendar day. For MAU, choose and justify one interpretation — calendar-month uniques or a rolling 30-day window — and explain the trade-off with the other. 2. **Event ingestion and data modeling.** Accept activity events from both web and mobile clients. Specify the required event fields. 3. **De-duplication and identity.** Handle duplicate events; define the canonical user key across `user_id`, `device_id`/`anonymous_id`, and logged-out users. 4. **Accurate DAU/MAU computation.** Address time-zone/day boundaries, late-arriving events, out-of-order events, and backfills. 5. **Storage and compute choices at large scale.** Justify your streaming vs. batch and exact vs. approximate counting decisions. 6. **Serving queries and dashboards.** Support near-real-time dashboards for product and leadership teams plus historical queries by date range, platform, country, and app version. Discuss latency, caching, and correctness guarantees. 7. **Monitoring, data quality, failure handling, and privacy.** Cover anomaly detection, reconciliation, fault tolerance, and PII/retention controls.

Quick Answer: A Vanta software-engineer system-design interview question: design a scalable pipeline to compute and serve DAU and MAU engagement metrics for a large consumer app. It tests event ingestion, identity and de-duplication, exact vs. approximate distinct counting (HyperLogLog/bitmaps), handling of time zones and late/out-of-order events, streaming-vs-batch correctness, dashboard serving, and monitoring/privacy.

|Home/System Design/Vanta

Design a DAU/MAU metrics system

Vanta logo
Vanta
Feb 23, 2026, 12:00 AM
mediumSoftware EngineerOnsiteSystem Design
61
0
Question

Design a system that computes and serves product engagement metrics — DAU (Daily Active Users) and MAU (Monthly Active Users) — for a large consumer application.

An "active user" is a distinct user who performed at least one qualifying event (e.g., app open, page view, login, session start) within the time window. DAU is the number of unique active users per calendar day. MAU is the number of unique active users over a month (you will choose and justify a precise interpretation).

Your design should cover the full path from client to dashboard, and specifically address:

  1. Metric definitions. For MAU, choose and justify one interpretation — calendar-month uniques or a rolling 30-day window — and explain the trade-off with the other.
  2. Event ingestion and data modeling. Accept activity events from both web and mobile clients. Specify the required event fields.
  3. De-duplication and identity. Handle duplicate events; define the canonical user key across user_id , device_id / anonymous_id , and logged-out users.
  4. Accurate DAU/MAU computation. Address time-zone/day boundaries, late-arriving events, out-of-order events, and backfills.
  5. Storage and compute choices at large scale. Justify your streaming-vs-batch and exact-vs-approximate counting decisions.
  6. Serving queries and dashboards. Support near-real-time dashboards for product and leadership teams plus historical queries by date range, platform, country, and app version. Discuss latency, caching, and correctness guarantees.
  7. Monitoring, data quality, failure handling, and privacy. Cover anomaly detection, reconciliation, fault tolerance, and PII/retention controls.

Constraints & Assumptions

  • Large consumer app: assume on the order of 10710^7107 – 10810^8108 active users and a high sustained event rate (hundreds of thousands to millions of events/sec at peak).
  • Events arrive from heterogeneous clients (web, iOS, Android) over unreliable networks, so duplicates, late arrivals, and out-of-order delivery are the norm, not the exception.
  • Dashboards need near-real-time freshness (seconds to low minutes) for "today"; finalized historical numbers are expected at T+1.
  • A small, governed set of slice dimensions (platform, country, app version); not arbitrary high-cardinality slicing.
  • A bounded error (~1-2%) is acceptable for dashboards; finance/compliance reporting needs exact numbers.
  • PII must be minimized and subject to retention policy.

Clarifying Questions to Ask

  • What counts as a "qualifying" event? Any event, or a curated allowlist (e.g., app_open , session_start )? This changes both the definition and the ingest volume.
  • Which MAU definition does the business actually use — calendar-month (board/finance) or rolling-30-day (product health)? Do we need to serve both?
  • What day boundary? UTC, or each user's local timezone? This determines which day an event lands in and complicates late handling.
  • What freshness and accuracy SLAs do dashboards require, and is approximate counting (HLL) acceptable, or must every number be exact?
  • Which dimensions must be sliceable (platform, country, app version, event type), and is per-user drill-down ever required?
  • Retention and privacy requirements — how long do we keep raw events vs. aggregates, and what PII can the event carry?

What a Strong Answer Covers

  • Precise definitions. "Active user" = distinct canonical user key with ≥1 qualifying event in the window; DAU as the daily primitive; an explicit, justified MAU interpretation (calendar-month vs. rolling-30-day) with the trade-off named; and a stated day-boundary timezone.
  • A layered architecture. Ingest gateway → durable log (Kafka/Kinesis/PubSub) → raw immutable archive (data lake) → aggregation (stream + batch) → OLAP/serving store → dashboards and a metrics API, with a clear lambda-style split between fast-provisional and authoritative-final.
  • Identity and de-duplication. A documented canonical-key rule across user_id / anonymous_id / device_id , the effect of identity stitching on historical counts, and dedup on event_id at both stream and batch layers.
  • Correct distinct counting. A reasoned choice among exact (distinct tables / Roaring Bitmaps) and approximate (HLL) structures, with MAU derived by merging daily structures, and the exact-vs-approximate trade-off (cost/memory vs. correctness) made explicit.
  • Event-time correctness. Watermarks and a lateness window; provisional-vs-final semantics; backfills via partition reprocessing; out-of-order handling by event-time bucketing.
  • Scale-aware storage/serving. Appropriate stores per layer, precomputed high-traffic rollups, a dimension allowlist / cardinality budget, plus caching and stated correctness guarantees on the serving path.
  • Operability and privacy. Anomaly detection, streaming-vs-batch reconciliation, replay/checkpointing/idempotency for fault tolerance, and PII minimization with retention tiers and access controls.

Follow-up Questions

  • How do HLL error bounds behave when you union 30 daily sketches for rolling MAU, and how would you bound or report the aggregate error to stakeholders?
  • A product team retroactively merges two anonymous identities into one user. How does that affect already-published historical MAU, and how do you communicate (or avoid) the restatement?
  • "Today's DAU dropped 15%." Walk through how your monitoring and reconciliation distinguish a real product regression from an ingestion outage, a dedup bug, or a late-data artifact.
  • Leadership wants the DAU/MAU stickiness ratio sliced by country and app version, refreshed every minute. What do you precompute, what do you compute on demand, and where does cardinality bite?

Submit Your Answer to Earn 20XP

Sign in to leave a comment

Loading comments...

Browse More Questions

More System Design•More Vanta•More Software Engineer•Vanta Software Engineer•Vanta System Design•Software Engineer System Design

Your design canvas — auto-saved

PracHub

Master your tech interviews with 8,500+ real questions from top companies.

Product

  • Questions
  • Learning Tracks
  • Interview Guides
  • Resources
  • Premium
  • For Universities
  • Student Access

Browse

  • By Company
  • By Role
  • By Category
  • Topic Hubs
  • SQL Questions
  • AI Coding Questions
  • Compare Platforms
  • Discord Community

Support

  • support@prachub.com
  • (916) 541-4762

Legal

  • Privacy Policy
  • Terms of Service
  • About Us

© 2026 PracHub. All rights reserved.