Design a local activity counter service

Quick Overview

This question evaluates a candidate's skills in designing large-scale distributed systems, focusing on near-real-time ingestion and aggregation, idempotency/deduplication, time-windowed (tumbling and sliding) analytics, hot-key sharding, storage and backfill strategies, and operational concerns including monitoring and privacy.

Design a local activity counter service

Company: Stripe

Role: Software Engineer

Category: System Design

Difficulty: hard

Interview Round: Technical Screen

Design a system that counts local application activities and operations per user, device, and region with high write throughput and near-real-time reads. Define APIs such as increment(key, timestamp), getCount(key), getCount(key, timeWindow), and getUniqueActors(key, window). Address idempotency and deduplication, exactly-once vs at-least-once tradeoffs, time-windowed aggregations (sliding and tumbling), hot-key sharding, storage choices (e.g., write-optimized store plus aggregation layers), offline client buffering and sync, retention and TTL, backfill and reprocessing, privacy considerations, and monitoring and alerting. Provide a capacity estimate and describe failure modes and mitigations.

Quick Answer: This question evaluates a candidate's skills in designing large-scale distributed systems, focusing on near-real-time ingestion and aggregation, idempotency/deduplication, time-windowed (tumbling and sliding) analytics, hot-key sharding, storage and backfill strategies, and operational concerns including monitoring and privacy.

|Home/System Design/Stripe
Stripe logo
Stripe
Sep 6, 2025, 12:00 AM
hardSoftware EngineerTechnical ScreenSystem Design
17
0

System Design: Near-Real-Time Activity Counting Service

Context

Build a service that ingests high-throughput client events and provides near-real-time aggregations of activity counts per user, device, and region. The system must support time-windowed queries (tumbling and sliding), deduplication/idempotency, hot-key sharding, and privacy-by-design. It should be resilient, observable, and support backfill/reprocessing.

Assume the service is multi-tenant and globally deployed with regional data residency. Reads should be near-real-time (seconds), writes are very high-throughput, and clients may be offline and sync later.

Requirements

  1. APIs
    • increment(key, timestamp)
    • getCount(key)
    • getCount(key, timeWindow)
    • getUniqueActors(key, timeWindow)
  2. System properties
    • High write throughput with near-real-time reads
    • Idempotency and deduplication for retries/replays
    • Discuss exactly-once vs at-least-once delivery tradeoffs
    • Time-windowed aggregations: tumbling and sliding
    • Hot-key sharding to avoid partition hotspots
    • Storage choices (e.g., write-optimized store + aggregation layers)
    • Offline client buffering and sync
    • Retention and TTL policies
    • Backfill and reprocessing strategy
    • Privacy considerations
    • Monitoring and alerting
    • Capacity estimate (state assumptions) and failure modes with mitigations

Submit Your Answer to Earn 20XP

Sign in to leave a comment

Loading comments...