Requirements: Connections and Recommendations - LinkedIn Connections: Designing Professional Social Graphs | OneNoughtOne

0/319

System Design HLDLinkedIn Connections

LinkedIn Connections: Designing Professional Social Graphs

LevelAdvanced

Duration90 mins

TopicLinkedIn Connections

1 / 5

Requirements: Connections and Recommendations

The Professional Network Challenge

LinkedIn represents one of the most sophisticated social graph systems ever built. With over 900 million members across 200 countries, 65 million daily active users, and billions of professional connections, it must solve problems that push the boundaries of distributed systems engineering.

Unlike social networks optimized for entertainment (Facebook, Instagram) or real-time communication (WhatsApp, Discord), LinkedIn's graph is fundamentally transactional and professional. Every connection represents a potential business relationship, career opportunity, or professional collaboration. The system must balance real-time responsiveness with professional credibility, supporting use cases from job searching to business development to thought leadership.

Designing such a system requires mastering graph storage and traversal at massive scale, implementing recommendation algorithms that surface valuable connections, and computing degrees of separation across a network where relationship quality matters as much as relationship quantity.

What You Will Learn

By completing this module, you will understand how to design a professional social network from first principles. You'll learn to analyze requirements for connection management, build recommendation systems for professional relationships, implement efficient graph traversal algorithms, and scale these systems to handle hundreds of millions of users and billions of edges.

Understanding the Problem Domain

Before diving into technical requirements, we must understand what makes professional social networks fundamentally different from other social platforms. This understanding shapes every subsequent design decision.

The Professional Context Difference:

Professional networks operate under different constraints than personal social networks:

Connection Quality Over Quantity — A LinkedIn connection represents a professional relationship, not just social acknowledgment. Users typically have 500-2000 connections, not 5000+ friends.
Bidirectional Trust — Unlike Twitter's follow model, LinkedIn connections are mutual. Both parties must agree, creating a graph of verified professional relationships.
Career Stakes — Actions on LinkedIn affect careers and reputations. The system must prevent spam, fake connections, and professional impersonation more aggressively than entertainment platforms.
Transactional Value — Connections enable business transactions: recruiting, sales, partnerships. The system must facilitate these without becoming a spam vector.
Credential Verification — Professional networks must validate claims about education, employment, and skills that affect hiring decisions.

Professional vs Personal Social Networks
Characteristic	Personal (Facebook/Instagram)	Professional (LinkedIn)
Connection Semantics	"We know each other"	"We can do business together"
Average Connections	300-500 friends	500-2000 connections
Connection Model	Often unidirectional (follows)	Always bidirectional (mutual)
Content Focus	Entertainment, personal updates	Professional achievements, industry insights
Primary Value	Social engagement, time spent	Career advancement, business development
Trust Requirement	Moderate (entertainment context)	High (financial/career implications)
Verification Need	Minimal (identity only)	Extensive (credentials, employment)
Spam Sensitivity	Annoying but tolerable	Career-damaging if pervasive

Key Stakeholders and Their Needs:

A LinkedIn-style system serves distinct stakeholder groups with overlapping but different requirements:

Individual Professionals:

Build and maintain professional network
Discover career opportunities
Showcase skills and achievements
Find and connect with industry peers
Receive relevant professional recommendations

Recruiters and HR:

Search candidate pools efficiently
Understand candidate networks and referrals
Reach passive job seekers
Verify professional claims
Track talent pipelines

Sales and Business Development:

Identify decision-makers at target companies
Find warm introduction paths
Build prospect lists
Research company hierarchies
Track relationship touchpoints

Enterprises:

Employee verification and background checks
Competitor intelligence
Talent pipeline analysis
Industry relationship mapping
Brand presence and thought leadership

The Graph Is the Product

Unlike content platforms where the feed is the product, in professional networks the graph itself—the relationships and their quality—is the core product. Every feature exists to create, maintain, or leverage these connections. This fundamental insight shapes all architectural decisions.

Core Functional Requirements

The functional requirements for a professional network span connection management, discovery, recommendations, and professional features. Let's analyze each category comprehensively.

Connection Management Requirements

•Send Connection Request — Users can send connection requests with optional personalized messages. Requests must be rate-limited and spam-filtered.
•Accept/Reject Request — Recipients can accept, reject, or ignore connection requests. Rejected requests should not be re-sendable immediately.
•Withdraw Request — Senders can withdraw pending requests. The system should track withdrawn requests to prevent harassment.
•Remove Connection — Users can remove existing connections. Removal should be silent (no notification to the removed party).
•Block User — Users can block other users, preventing all interaction. Blocking is asymmetric—the blocked user shouldn't know they're blocked.
•Connection Visibility — Users control who can see their connections (everyone, connections only, or hidden).
•Connection Notes — Private notes on connections for CRM-like tracking (premium feature).
•Connection Tags — Organize connections into categories (colleagues, clients, prospects).

Discovery and Search Requirements

•People Search — Search by name, company, title, location, skills, and other professional attributes with faceted filtering.
•Company Search — Find companies and see employees, including who in your network works there.
•Connection Path — Show how you're connected to any user (mutual connections, degrees of separation).
•Browse Connections — View and filter your own connections by various criteria.
•Network Updates — See career updates from your network (new jobs, promotions, work anniversaries).
•Profile Views — See who viewed your profile (with privacy controls for premium).
•Alumni Search — Find former colleagues and classmates from shared companies and schools.

Recommendation Requirements

•People You May Know (PYMK) — Suggest potential connections based on network overlap, work history, skills, and other signals.
•Connection Suggestions on Profile — When viewing a profile, suggest relevant connections from that person's network.
•Similarity Scoring — Quantify professional similarity between users for matching.
•Warm Introduction Path — Identify optimal paths for warm introductions to target individuals.
•Skill Endorsements — Enable connections to endorse skills, creating trust signals.
•Recommendation Letters — Formal written recommendations from connections.
•Job Recommendations — Suggest jobs based on connection's companies and referral opportunities.

Professional Features:

Beyond basic networking, professional platforms require specialized features:

Profile Management:

Complete professional history (employment, education)
Skills and endorsements
Certifications and licenses
Portfolio and work samples
Publications and patents
Volunteer experience
Languages and proficiency

Professional Credential Features:

Employment verification
Education verification
Skill assessments/tests
Certification validation
Background check integration

Engagement Features:

Professional content feed
Articles and long-form content
Comments and reactions
Sharing and reposting
Hashtags and topics
Groups and communities

Premium Features:

InMail (message non-connections)
Advanced search filters
See all profile viewers
Salary insights
Learning courses
Sales Navigator features

Non-Functional Requirements

Non-functional requirements for a professional network are demanding due to the scale of the graph and the real-time nature of recommendations. Let's establish the key constraints.

Scale Requirements (LinkedIn-Scale Reference)
Metric	Target	Implications
Total Users	900+ million	Massive node count in graph
Daily Active Users	65+ million	Concurrent read/write load
Total Connections	Billions (est. 50B+)	Edge storage at extreme scale
Avg Connections/User	500-2000	Dense local neighborhoods
Connection Requests/Day	100+ million	High write throughput
Search Queries/Day	Billions	Index scale and query complexity
PYMK Computations/Day	Billions	Recommendation compute cost
Profile Views/Day	Billions	Read-heavy workload

Performance Requirements

•Connection Actions — Send/accept/reject requests must complete in <200ms for responsive UX.
•Profile Loading — Profile pages must load in <500ms including connection count and mutual connections.
•People Search — Search results must return in <300ms even with complex filters.
•PYMK Loading — Recommendations must load in <500ms (can be precomputed).
•Degrees of Separation — Connection path computation should complete in <1s for up to 3 degrees.
•Mutual Connections — Mutual connection list must compute in <200ms.
•Graph Traversal — 2nd-degree network enumeration within <2s for network of 1000 connections.
•Real-time Updates — Career updates and activity should propagate within 5 seconds.

Availability and Reliability Requirements

•System Availability — 99.99% uptime (< 53 minutes downtime per year). Career-critical actions cannot fail during business hours.
•Connection Durability — Zero tolerance for connection loss. Once connected, the relationship must never disappear unexpectedly.
•Request Delivery — Connection requests must have exactly-once delivery semantics. Duplicate or lost requests erode trust.
•Data Consistency — Connection state must be strongly consistent. Seeing "Connected" for one party and "Pending" for another is unacceptable.
•Graceful Degradation — If recommendations fail, core connection features must remain operational.
•Regional Availability — Multi-region deployment for global professional workforce.
•Disaster Recovery — RPO < 5 minutes, RTO < 30 minutes for full system recovery.

Scalability Requirements:

The system must scale across multiple dimensions:

User Growth:

Handle 10% annual user growth without architectural changes
Scale from 900M to 2B users without redesign
Support regional expansion with data locality requirements

Graph Density:

Handle increasing connections per user (network effect)
Support power users with 30,000+ connections
Manage celebrity/influencer nodes with millions of followers (asymmetric follow model)

Feature Expansion:

Add new relationship types (follow, mentor, colleague)
Integrate new professional contexts (gig work, skills marketplace)
Support B2B features (Sales Navigator, Recruiter)

Query Complexity:

Scale graph traversal as network density increases
Handle complex multi-hop queries efficiently
Support real-time analytics on graph structure

The Supernode Problem

Power users and celebrities create 'supernodes' in the graph—users with orders of magnitude more connections than average. A CEO with 30,000 connections or an influencer with 2 million followers requires specialized handling. Naive algorithms that work for average users will timeout or crash when encountering supernodes. Every graph operation must be designed with supernode resilience.

Data Modeling Fundamentals

Designing the data model for a professional network requires careful consideration of the entities, relationships, and the graph structure that connects them.

Core Entity Models
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
// Core User/Member Entity
interface Member {
  id: string;                    // Globally unique member ID
  publicId: string;              // URL-safe public identifier
  firstName: string;
  lastName: string;
  headline: string;              // Professional headline ("Senior Engineer at FAANG")
  location: Location;            // Current location
  industry: string;              // Primary industry
  profilePhoto: string;          // Photo URL
  connectionCount: number;       // Cached connection count
  followerCount: number;         // For influencer/creator mode
  createdAt: Date;
  lastActive: Date;
  privacySettings: PrivacySettings;
  membershipLevel: 'free' | 'premium' | 'sales_navigator' | 'recruiter';
}
 
// Professional Experience
interface Position {
  id: string;
  memberId: string;
  companyId: string;
  title: string;
  description: string;
  startDate: Date;
  endDate: Date | null;          // null = current position
  location: Location;
  isCurrent: boolean;
}
 
// Connection Entity (the edge in our graph)
interface Connection {
  id: string;
  memberId1: string;             // Lower ID always first (canonical ordering)
  memberId2: string;
  connectedAt: Date;
  connectionSource: ConnectionSource;  // How they connected
  notes: ConnectionNotes;        // Private notes (premium feature)
  tags: string[];                // User-defined tags
}
 
// Connection Request (pending edge)
interface ConnectionRequest {
  id: string;
  senderId: string;
  recipientId: string;
  message: string | null;        // Optional personalized message
  sentAt: Date;
  status: 'pending' | 'accepted' | 'rejected' | 'withdrawn';
  respondedAt: Date | null;
  source: RequestSource;         // PYMK, profile view, search, etc.
}
 
// Block relationship (asymmetric)
interface Block {
  blockerId: string;
  blockedId: string;
  blockedAt: Date;
  reason: string | null;
}
 
type ConnectionSource = 
  | 'search'
  | 'pymk'                       // People You May Know
  | 'profile_view'
  | 'content_engagement'
  | 'event'
  | 'import'                     // Email/address book import
  | 'company_page'
  | 'school_page'
  | 'group'
  | 'inmail';
 
type RequestSource = ConnectionSource;

Graph Modeling Considerations:

The connection graph is an undirected graph for bidirectional connections, but also includes directed edges for follows (asymmetric relationships). This hybrid model requires careful modeling:

Adjacency Representation: For each user, we need to efficiently answer:

Who are my direct connections?
Who are my 2nd-degree connections?
What mutual connections do I have with user X?
What is the shortest path to user Y?
Who in my network works at company Z?

Storage Trade-offs:

Graph Storage Approaches
Approach	Pros	Cons	Use Case
Adjacency List (DB)	Simple queries, ACID transactions	Expensive traversals, join overhead	Connection CRUD operations
Adjacency Matrix	O(1) connection check	O(n²) space—infeasible at scale	Small dense subgraphs only
Graph Database (Neo4j)	Native traversal, flexible queries	Scaling challenges, operational complexity	Complex path queries
Materialized Edges	Fast reads, precomputed paths	Storage cost, update complexity	PYMK, mutual connections
Hybrid Approach	Optimized per query pattern	System complexity	Production LinkedIn-scale

Graph Data Structures
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
// Adjacency List representation for a member's network
interface MemberNetwork {
  memberId: string;
  
  // Direct connections (1st degree)
  connections: Set<string>;
  
  // Pending requests
  sentRequests: Map<string, ConnectionRequest>;
  receivedRequests: Map<string, ConnectionRequest>;
  
  // Blocked users (for filtering)
  blocked: Set<string>;
  blockedBy: Set<string>;
  
  // Followers (asymmetric follow relationship)
  followers: Set<string>;
  following: Set<string>;
  
  // Cached computed values (refreshed periodically)
  secondDegreeCount: number;
  lastSecondDegreeCompute: Date;
}
 
// For efficient mutual connection queries
interface ConnectionPair {
  // Store sorted pair for O(1) lookup
  canonicalKey: string;  // Format: "smaller_id:larger_id"
  member1: string;
  member2: string;
  connectedAt: Date;
  
  // Precomputed mutual connection count
  mutualCount: number;
  mutualCountUpdatedAt: Date;
}
 
// Edge metadata for rich connection information
interface ConnectionEdge {
  source: string;
  target: string;
  
  // Relationship metadata
  relationship: EdgeRelationship;
  createdAt: Date;
  
  // Shared context (for PYMK ranking)
  sharedCompanies: string[];
  sharedSchools: string[];
  sharedGroups: string[];
  sharedSkills: string[];
  
  // Interaction signals
  lastInteraction: Date;
  interactionCount: number;
  messageCount: number;
}
 
type EdgeRelationship = 
  | 'connection'
  | 'follow'
  | 'teammate'      // Worked together at same company
  | 'classmate'     // Attended same school
  | 'colleague'     // Same company, different team
  | 'mentor'        // Explicit mentorship relationship
  | 'recruiter';    // Recruiter-candidate relationship

Recommendation Requirements Deep Dive

The "People You May Know" (PYMK) feature is critical for network growth and user engagement. It must balance relevance (suggesting connections users actually want) with diversity (introducing users to new professional circles) while avoiding spam (suggesting irrelevant or unwanted connections).

PYMK Signal Categories

•Graph Proximity Signals — Mutual connections, connection of connections, shortest path distance. The more mutual friends, the higher the recommendation score.
•Professional Context Signals — Shared employers (current or past), shared schools, same industry, similar job titles, overlapping skills.
•Temporal Signals — Recent profile views, recent interactions, newly connected mutual friends, active job seekers.
•Engagement Signals — Content interactions, group memberships, event attendance, message history.
•Explicit Signals — Address book imports, email contacts, connection request history (accepted/rejected).
•Negative Signals — Previously rejected requests, blocks, spam reports, low acceptance rate from suggested connections.

Recommendation Quality Metrics:

We must measure recommendation effectiveness to continuously improve:

Primary Metrics:

Acceptance Rate: What percentage of shown recommendations result in connection requests?
Organic Connections: Of sent requests, what percentage are accepted?
Click-Through Rate: What percentage of recommendations are clicked (profile viewed)?
Time to Action: How quickly do users act on recommendations?

Secondary Metrics:

Network Quality: Do recommended connections lead to meaningful interactions?
Engagement Lift: Do users who accept recommendations become more active?
Churn Impact: Do irrelevant recommendations drive users away?
Diversity Score: Are recommendations expanding professional circles or creating echo chambers?

Anti-Metrics (What to Avoid):

Recommendations to/from blocked users
Repeated recommendations of rejected candidates
Recommendations that result in spam reports
Recommendations with zero professional overlap

The Cold Start Problem

New users have no connection graph to leverage for recommendations. The system must bootstrap from sparse signals: email contacts, company/school selection during signup, profile information, and job search behavior. Cold start recommendations often rely more heavily on demographic matching and content-based filtering until sufficient graph signal accumulates.

Recommendation Personalization Axes:

Recommendations should be personalized across multiple dimensions:

1. Career Stage:

Students: Recommend alumni, professors, internship contacts
Early career: Recommend peers, potential mentors, industry professionals
Mid-career: Recommend industry peers, cross-functional contacts, thought leaders
Executives: Recommend other executives, board members, advisors

2. Current Intent:

Job seeking: Recommend recruiters, employees at target companies
Hiring: Recommend potential candidates, referral sources
Business development: Recommend decision-makers at target accounts
Learning: Recommend experts in areas of interest

3. Network Density:

Sparse network: Focus on building foundational connections
Medium network: Balance between close ties and new circles
Dense network: Focus on strategic, high-value connections

4. Engagement Pattern:

Active users: Surface more diverse, exploratory recommendations
Passive users: Focus on high-confidence, obviously relevant recommendations
Returning users: Highlight what they missed, new potential connections

Privacy and Security Requirements

Professional networks handle sensitive career information, making privacy and security paramount. Breaches or privacy violations have career-affecting consequences.

Privacy Requirements

•Connection Visibility Control — Users choose who sees their connections: public, only connections, or completely private.
•Profile View Privacy — Users control whether they appear in profile view lists. Private browsing hides viewer identity.
•Activity Broadcasting — Users control which activities (job changes, connections, content) are broadcast to network.
•Search Visibility — Users can opt out of being discoverable in member search results.
•Data Export — GDPR/CCPA compliance requires full data export capability, including all connections and interactions.
•Right to Erasure — Users can delete their account, requiring cascade deletion of all personal data while preserving aggregate analytics.
•Cross-Border Data Flows — Handle international data transfer regulations (EU-US Privacy Shield, data localization requirements).

Security Requirements

•Authentication — Strong authentication with MFA, SSO integration for enterprise customers.
•Session Management — Secure session handling, concurrent session limits, suspicious login detection.
•API Security — Rate limiting, OAuth 2.0 for third-party apps, scope-limited access tokens.
•Data Encryption — Encryption at rest and in transit, field-level encryption for sensitive data.
•Fraud Prevention — Detect and prevent fake accounts, impersonation, and credential stuffing.
•Abuse Prevention — Rate limit connection requests, detect spam patterns, prevent harassment.
•Audit Logging — Comprehensive audit trail for sensitive actions (data access, permission changes).

The Visibility Paradox

Users want their profile visible for career opportunities but invisible to current employers when job searching. They want to see who viewed them but browse others privately. The system must support nuanced, context-dependent privacy that balances discoverability with discretion.

API Requirements

The API layer must support multiple clients (web, mobile, third-party integrations) while maintaining security and performance. Let's define the core API contracts.

Core Connection APIs
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
// Connection Management APIs
interface ConnectionAPI {
  // Send a connection request
  // POST /v2/connections/requests
  sendConnectionRequest(params: {
    recipientId: string;
    message?: string;           // Optional personalized message (300 char limit)
    source: RequestSource;      // Analytics: where did this originate
  }): Promise<{
    requestId: string;
    status: 'sent' | 'already_connected' | 'already_pending' | 'blocked';
  }>;
 
  // Respond to a connection request
  // PUT /v2/connections/requests/{requestId}
  respondToRequest(params: {
    requestId: string;
    action: 'accept' | 'reject' | 'ignore';
  }): Promise<{
    status: 'accepted' | 'rejected' | 'ignored';
    connectionId?: string;      // Set if accepted
  }>;
 
  // Remove a connection
  // DELETE /v2/connections/{connectionId}
  removeConnection(params: {
    connectionId: string;
    reason?: string;            // Optional for analytics
  }): Promise<void>;
 
  // Get pending connection requests
  // GET /v2/connections/requests
  getRequests(params: {
    direction: 'sent' | 'received';
    status?: 'pending' | 'all';
    pagination: PaginationParams;
  }): Promise<{
    requests: ConnectionRequest[];
    pagination: PaginationResult;
  }>;
 
  // Get connections for a member
  // GET /v2/members/{memberId}/connections
  getConnections(params: {
    memberId: string;
    sortBy?: 'recent' | 'name' | 'company';
    filters?: ConnectionFilters;
    pagination: PaginationParams;
  }): Promise<{
    connections: ConnectionSummary[];
    totalCount: number;
    pagination: PaginationResult;
  }>;
 
  // Get mutual connections between viewer and target
  // GET /v2/members/{memberId}/mutual-connections
  getMutualConnections(params: {
    memberId: string;
    pagination: PaginationParams;
  }): Promise<{
    mutualConnections: MemberSummary[];
    totalCount: number;
    pagination: PaginationResult;
  }>;
}
 
// Recommendation APIs
interface RecommendationAPI {
  // Get PYMK recommendations
  // GET /v2/recommendations/pymk
  getPYMK(params: {
    count?: number;             // Default 10, max 50
    offset?: number;
    context?: 'feed' | 'profile' | 'network_page';
    excludeIds?: string[];      // Already shown/dismissed
  }): Promise<{
    recommendations: PYMKRecommendation[];
  }>;
 
  // Dismiss a recommendation
  // POST /v2/recommendations/pymk/{memberId}/dismiss
  dismissRecommendation(params: {
    memberId: string;
    reason?: 'not_relevant' | 'dont_know' | 'inappropriate';
  }): Promise<void>;
 
  // Get connection paths to a member
  // GET /v2/members/{memberId}/connection-paths
  getConnectionPaths(params: {
    memberId: string;
    maxDegrees?: number;        // Default 3, max 4
    maxPaths?: number;          // Default 5
  }): Promise<{
    degrees: number;            // Degree of separation
    paths: ConnectionPath[];
    mutualConnections: MemberSummary[];
  }>;
}
 
// Response Types
interface PYMKRecommendation {
  member: MemberSummary;
  score: number;                // Relevance score (internal)
  reasons: RecommendationReason[];
  mutualConnectionCount: number;
  mutualConnections: MemberSummary[];  // First 3 mutual
  sharedCompanies: Company[];
  sharedSchools: School[];
}
 
interface RecommendationReason {
  type: 'mutual_connections' | 'same_company' | 'same_school' 
      | 'same_industry' | 'similar_skills' | 'viewed_profile';
  detail: string;               // "32 mutual connections"
}
 
interface ConnectionPath {
  path: MemberSummary[];        // Ordered list from viewer to target
  strength: number;             // Path quality score
}

Success Criteria and Acceptance Testing

Clear success criteria ensure we're building the right system. Let's define measurable acceptance criteria for the LinkedIn Connections system.

Acceptance Criteria Summary
Feature	Success Criteria	Measurement Method
Connection Request Send	< 200ms p99 latency, 99.99% success rate	APM metrics, synthetic monitoring
Request Accept/Reject	< 150ms p99, immediate visibility for both parties	End-to-end timing, consistency tests
Mutual Connections	< 200ms for up to 100 mutual, accurate count	Load testing, correctness validation
PYMK Relevance	5% click-through, > 15% action rate	A/B testing, analytics pipeline
Connection Path	Correct shortest path, < 1s for 3 degrees	Graph validation tests, load testing
Search Results	< 300ms p95, relevant ranking	Latency monitoring, relevance scoring
Privacy Controls	100% enforcement, audit verification	Security testing, compliance audits
Data Consistency	Zero split-brain on connection state	Consistency test suite, chaos testing

Key Testing Scenarios

•Concurrent Connection Management — Two users simultaneously accept/reject the same request—exactly one outcome must succeed.
•Supernode Operations — All operations complete within SLA for users with 30,000+ connections.
•Privacy Enforcement — Connection list invisible to non-connections when privacy is set to 'connections only'.
•PYMK Quality — Recommendations do not include blocked users, previously rejected candidates, or users with no professional overlap.
•Path Computation Accuracy — Shortest path is actually shortest; degrees of separation are accurate.
•Cross-Region Consistency — Connection state consistent across all regions within 5 seconds.
•Graceful Degradation — When recommendation service is down, connection features remain fully operational.

Requirements Phase Complete

You now have a comprehensive understanding of the requirements for a LinkedIn-style professional network. We've covered functional requirements (connections, recommendations, discovery), non-functional requirements (scale, performance, availability), data modeling fundamentals, privacy/security constraints, and API contracts. In the next page, we'll dive into graph storage and traversal—the core technical challenge of building social graphs at scale.