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

SeniorPrefer not to say

Jun 2026

Summary

LinkedIn system design round for a software engineering role. The whole thing was one big open-ended question about building a company-wide monitoring platform, and they expected you to go pretty deep across a lot of dimensions. Felt like a gauntlet.

Questions Asked (1)

Design a company-wide monitoring system that covers metrics, logs, traces, and events from both services and infrastructure. Walk through ingestion at scale, time-series storage, querying and dashboarding, alerting with on-call routing, multi-tenancy across teams, data retention with downsampling, high availability of the monitoring stack itself, and the trade-offs between push and pull collection models.

System DesignTechnical Trade-offs

Author's notes

This is basically five interviews in one question.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements and scale, then propose a high-level architecture that separates ingestion, storage, and query layers. Walk through each component (metrics, logs, traces, events) and address the specific concerns (ingestion, storage, querying, alerting, multi-tenancy, retention, HA, push vs pull) in a logical order, highlighting trade-offs and choices.

Pro tip: Emphasize that monitoring is a product with its own SLOs; treat the monitoring stack as a critical service and design for its own observability and failure modes. Also, mention that at LinkedIn scale, a hybrid push/pull model with a centralized pipeline is often necessary to handle diverse sources and ensure reliability.

1. Clarify Requirements and Scale

Ask questions to understand the scale (number of services, hosts, data volume, retention needs), latency requirements, and existing infrastructure. This ensures the design is appropriately sized and avoids over-engineering.

2. High-Level Architecture

Outline the main components: ingestion (collectors, agents, gateways), storage (time-series DB, log store, trace store), query and dashboarding, alerting, and multi-tenancy. Explain how data flows from sources to storage and then to consumers.

3. Deep Dive into Key Areas

For each area (ingestion at scale, storage and retention, querying, alerting, multi-tenancy, HA), discuss specific technologies, patterns, and trade-offs. For example, use Kafka for ingestion buffering, Prometheus for metrics with remote write, Elasticsearch for logs, Jaeger for traces, and Thanos/Cortex for long-term storage.

4. Address Push vs Pull and Trade-offs

Compare push and pull models: pull simplifies service discovery and reduces client complexity but can miss short-lived jobs; push handles dynamic environments but requires a reliable gateway. Propose a hybrid approach and justify it.

5. Summarize and Discuss Trade-offs

Recap the design, emphasizing how it meets the requirements. Discuss key trade-offs such as consistency vs availability, cost vs retention, and complexity vs flexibility. Mention potential bottlenecks and how to mitigate them.

Key Points to Mention

Use of Kafka or similar for scalable ingestion and buffering to handle bursts and decouple producers from consumers.
Time-series storage options: Prometheus with remote write to Thanos/Cortex for long-term storage and downsampling; consider VictoriaMetrics or InfluxDB.
Multi-tenancy: enforce isolation via namespaces, RBAC, and resource quotas; use separate storage partitions or clusters per tenant if needed.
Alerting: use Alertmanager for deduplication, grouping, and routing to on-call systems like PagerDuty; define SLOs and error budgets.
High availability: deploy monitoring components in HA mode (e.g., multiple replicas, sharding), use replicated storage, and ensure the monitoring stack is self-monitoring.
Push vs pull: pull is simpler for service discovery and reduces client overhead; push is better for short-lived jobs and dynamic environments; hybrid model often best.

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