← LinkedIn Interview Insights

LinkedIn·Software Engineer·Onsite - System Design / Architecture·Senior

SeniorPrefer not to say
Jun 2026

Summary

LinkedIn system design round focused entirely on building a metrics platform from scratch, think Datadog or Prometheus but you have to justify every layer yourself. Solid challenge, lots of ground to cover.

Questions Asked (1)

Q1

Design a metrics collection and query platform similar to Datadog or Prometheus, covering agent-based collection from many hosts, an ingestion pipeline, time-series storage with compression and downsampling, a query layer for dashboards and ad-hoc queries, multi-tenant isolation, and independent scaling of ingest versus query. Alerting is out of scope.

System DesignTechnical Trade-offsData Modeling
Author's notes

This is basically a full distributed systems design in one question.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements and scale (e.g., number of hosts, metrics per second, retention, query latency) to frame the design. Then walk through the end-to-end architecture: agent-based collection, ingestion pipeline, time-series storage with compression/downsampling, query layer, and multi-tenant isolation. Emphasize how ingest and query can scale independently and discuss trade-offs at each layer.

Pro tip: Anchor your design around the data model and access patterns: metrics are time-series with high write throughput and range-scan reads, so choose storage and indexing accordingly. Also, explicitly call out how you'd handle cardinality explosion and tenant isolation, as these are common failure points in real systems.

1. Clarify Requirements and Scale

Ask questions to understand scale (hosts, metrics/sec, retention), query patterns (dashboards vs ad-hoc), and multi-tenancy needs. This ensures the design is grounded in realistic constraints.

2. Design Collection and Ingestion

Describe agent-based collection (e.g., pull vs push), buffering, and an ingestion pipeline that validates, enriches, and routes data. Discuss partitioning and backpressure to handle high throughput.

3. Design Storage Layer

Propose a time-series storage engine with compression (e.g., delta-of-delta, Gorilla) and downsampling/retention policies. Explain how data is partitioned (time, series) and indexed for efficient range queries.

4. Design Query Layer

Outline a query service that supports dashboards and ad-hoc queries, with caching, query planning, and pushdown of filters. Discuss how to isolate query workloads from ingest.

5. Address Multi-Tenancy and Scaling

Explain tenant isolation (e.g., separate namespaces, resource quotas) and how ingest and query components scale independently (e.g., separate clusters, autoscaling).

Key Points to Mention

  • Agent-based collection: pull vs push models, service discovery, and handling agent failures.
  • Ingestion pipeline: partitioning (e.g., by tenant/metric), replication, and exactly-once semantics.
  • Time-series storage: compression techniques (delta encoding, Gorilla), downsampling, and retention policies.
  • Query layer: query federation, caching, and optimizing for range scans and aggregations.
  • Multi-tenant isolation: resource quotas, noisy neighbor prevention, and data segregation.
  • Independent scaling: separate ingest and query clusters, autoscaling based on load, and decoupling via message queues.

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.