← LinkedIn Interview Insights

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

SeniorPrefer not to say
Apr 2026

Summary

LinkedIn system design round, one big question that sprawled into basically every subsystem you can think of. The scope was wider than I expected and I kept second-guessing whether to go deeper on caching or spend more time on the ingest pipeline.

Questions Asked (1)

Q1

Design an isMalicious(item) API service that, given a URL, IP address, file hash, or email, returns whether it is known to be malicious. Cover the API contract and latency/throughput targets, how you store and refresh threat intelligence data, a multi-tier read path with caching and a Bloom filter, propagation of new entries, regional replication, and monitoring.

System DesignTechnical Trade-offsAPI & Integrations
Author's notes

This one ate the whole session.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying the API contract and non-functional requirements (latency, throughput, consistency). Then design a multi-tier read path with caching and a Bloom filter to minimize latency, and describe how threat data is ingested, stored, refreshed, and propagated across regions. Finally, cover monitoring and trade-offs.

Pro tip: Emphasize the trade-off between false positives and false negatives, and how the Bloom filter's false positive rate affects the cache layer. Also, discuss how to handle stale data during propagation and the importance of idempotent updates.

1. Clarify requirements and API contract

Define the input types (URL, IP, hash, email), output format (boolean or score), and non-functional requirements like p99 latency (<50ms), throughput (100K QPS), and consistency (eventual).

2. Design data storage and refresh

Choose a scalable store (e.g., Cassandra, DynamoDB) for threat intelligence, and describe ingestion pipelines (batch and streaming) with periodic refresh from feeds.

3. Build multi-tier read path

Implement a Bloom filter for fast negative checks, an in-memory cache (e.g., Redis) for hot entries, and a persistent store for cold data, with fallback logic.

4. Plan propagation and regional replication

Use a pub/sub system (e.g., Kafka) to propagate new entries to all regions, and replicate data across regions with eventual consistency, considering latency and cost.

5. Define monitoring and trade-offs

Monitor latency, error rates, cache hit ratio, Bloom filter false positive rate, and data freshness. Discuss trade-offs like false positives vs. negatives and consistency vs. availability.

Key Points to Mention

  • API contract: input types, output format, error handling, and rate limiting.
  • Latency and throughput targets: p99 < 50ms, 100K QPS, and how to achieve them with caching and Bloom filters.
  • Threat intelligence storage: use a distributed database with TTL for automatic expiry, and refresh via batch/streaming.
  • Multi-tier read path: Bloom filter (false positive rate ~1%), in-memory cache (Redis), and persistent store (Cassandra).
  • Propagation: use Kafka for real-time updates and ensure idempotent writes to avoid duplicates.
  • Regional replication: active-active setup with eventual consistency, and monitoring for replication lag.

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