Design a LinkedIn Endorsements System

Medium45 min
1 / 30
understanding•10 min read

Problem Statement: A Social Graph Write-Heavy Endorsement Platform

Frames the endorsements system as a write-heavy social graph problem with count aggregation, suggestion generation, and trust-safety constraints.

Problem Statement

Design the skill endorsements subsystem of a professional networking platform at LinkedIn's scale. Users can endorse their connections for specific skills with a single click. The system must display accurate endorsement counts per skill, generate contextual endorsement suggestions based on mutual connections and shared work history, prevent bogus or gamed endorsements through trust-and-safety mechanisms, and support skill-based search optimization for recruiter queries.

This is not a simple counter-increment problem. An endorsement is a social graph edge with semantic weight, a count aggregation event that fans out to profile rendering, search indexes, notification pipelines, and suggestion engines, and a trust signal that must be validated against fraud patterns. A single endorsement click triggers writes to at least five downstream systems.

Why This Problem Is Distinctive

A like button on a social media post can tolerate approximate counts. A skill endorsement carries professional reputation weight—recruiters filter candidates by endorsed skills, and endorsement counts influence profile ranking in search results. The system must balance write throughput (billions of endorsements over the platform lifetime) with count accuracy visible to users within seconds, while preventing manipulation that degrades the signal quality of the entire professional graph.

Public Scale Context

LinkedIn reports over 1 billion members across 200+ countries as of 2024, with approximately 310 million monthly active users. The platform's skill taxonomy contains 39,000+ standardized skills. LinkedIn engineering has publicly discussed handling millions of writes per second across their data infrastructure built on Kafka, Venice, and Espresso. The endorsements feature, launched in 2012, has accumulated billions of endorsement events.

For capacity planning in this design, we assume a mature platform with 500 million members with profiles, 150 million daily active users, 50 million endorsement actions per day, and a 3x peak multiplier during weekday business hours. Unless a number is tied to a public source, it is an explicitly stated design assumption.

The Four Architectural Planes

  1. Write Path: Endorsement creation, validation, deduplication, and durable storage.
  2. Aggregation Path: Count computation, materialized views, cache invalidation, and eventual consistency guarantees.
  3. Suggestion Path: Social graph traversal, mutual connection computation, ranking, and personalized recommendation.
  4. Trust Path: Spam detection, rate limiting, endorsement quality scoring, and enforcement actions.

A strong interview answer keeps these planes separate. It allows the write path to degrade without losing endorsements, permits the aggregation path to be eventually consistent while maintaining user-visible freshness, and ensures the trust path can reject or reverse endorsements without blocking the core write flow.

Key Highlights

  • •An endorsement is simultaneously a social graph edge, a count aggregation event, and a trust signal requiring validation.
  • •LinkedIn reports 1B+ members and 39,000+ skills; our design assumes 50M endorsements/day with 3x peak.
  • •The architecture has four planes: write path, aggregation path, suggestion path, and trust path.
  • •Count accuracy visible within seconds requires materialized views, not on-demand computation.
  • •Professional reputation weight means approximate counts are insufficient—bounded staleness with correction is required.
Lead With Write Amplification
State in the first two minutes that a single endorsement click triggers writes to count aggregation, search index, notification, suggestion invalidation, and the social graph. This instantly frames the problem as write-heavy fan-out, not a simple counter.
Do Not Treat This as a Counter
A design that stores a count and increments it atomically misses the social graph semantics, the suggestion engine dependency, the trust validation requirement, and the search index update. Interviewers will probe these gaps immediately.

Section Rescue Kit

Buzzwords to use:

Write AmplificationBounded Staleness

Safe statements:

  • "I will separate the endorsement event from its derived projections—counts, suggestions, search entries—because they have different consistency and availability requirements."
  • "Before selecting databases, let me define which operations are latency-sensitive user-facing reads versus asynchronous background processing."
Design a LinkedIn Endorsements System - System Design | WinJob | WinJob