Collect and Query Recent User Activity

Read the full interview experience this question came from →

Quick Overview

Design a user-activity pipeline for minute, hour, and day queries, with durable ingestion, time-aware storage, deduplication, late data, and clear freshness.

Collect and Query Recent User Activity

Company: LinkedIn

Role: Software Engineer

Category: System Design

Difficulty: medium

Interview Round: Onsite

Design a user-activity collection system that supports queries over recent periods such as the last minute, hour, and day. Explain the path from collection API through middleware and storage to the query service. Clarify what an activity contains, whether queries return events or aggregates, how users and activity types are filtered, and which clock defines the requested period. The source supplies no fixed traffic target, schema, or lateness policy. ### What a Strong Answer Covers - Event identity, ownership, timestamps, validation, and ingestion durability. - Storage and indexing connected to the required time-range queries. - Duplicate events, late arrival, partial windows, and query freshness. - Partitioning, retention, backpressure, and failure recovery. ### Follow-up Questions - How would you avoid counting a retried event twice? - How would the result change when an event arrives late but belongs inside the requested period?

Overview: Design a user-activity pipeline for minute, hour, and day queries, with durable ingestion, time-aware storage, deduplication, late data, and clear freshness.

Read the full LinkedIn Software Engineer interview experience this question came from

|Home/System Design/LinkedIn
LinkedIn logo
LinkedIn
Aug 27, 2026
mediumSoftware EngineerOnsiteSystem Design
3
0

Design a user-activity collection system that supports queries over recent periods such as the last minute, hour, and day. Explain the path from collection API through middleware and storage to the query service.

Clarify what an activity contains, whether queries return events or aggregates, how users and activity types are filtered, and which clock defines the requested period. The source supplies no fixed traffic target, schema, or lateness policy.

What a Strong Answer Covers Guidance

  • Event identity, ownership, timestamps, validation, and ingestion durability.
  • Storage and indexing connected to the required time-range queries.
  • Duplicate events, late arrival, partial windows, and query freshness.
  • Partitioning, retention, backpressure, and failure recovery.

Follow-up Questions Guidance

  • How would you avoid counting a retried event twice?
  • How would the result change when an event arrives late but belongs inside the requested period?

Submit Your Answer to Earn 20XP

Sign in to leave a comment

Loading comments...