Social Network

Introduction

The Power of Serverless on AWS

Serverless computing on AWS offers unparalleled scalability, flexibility, and cost-efficiency, making it an ideal choice for modern application architectures. By leveraging services like AWS Lambda, API Gateway, DynamoDB, and S3, developers can build highly responsive and event-driven applications without worrying about infrastructure management. This architecture allows businesses to focus on delivering value quickly while maintaining resilience and performance.

One of the most compelling use cases for serverless is in building social networks. Traditional architectures often struggle with traffic spikes, high operational costs, and monolithic codebases that slow down innovation. Serverless addresses these challenges by providing automatic scaling, pay-per-use pricing, and event-driven workflows that allow for independent feature deployment.

Inspiration for This Article and System Design

The inspiration for this design comes from real-world experiences and insights shared by experts such as Yan Cui in his work How to Build a Social Network Entirely on Serverless. The case study details how serverless can transform a monolithic social platform into a highly scalable, event-driven system that efficiently handles unpredictable traffic surges, reduces operational costs, and accelerates feature releases.

By adopting a serverless-first approach, we aim to achieve:

• Improved developer velocity through independent and rapid deployments.
• Cost efficiency by eliminating over-provisioned infrastructure.
• Scalability to handle millions of users dynamically.
• Event-driven architecture for better system modularity and resilience.

This document provides a comprehensive breakdown of how to build a social network leveraging AWS serverless services, inspired by industry best practices and real-world implementations.

System Requirements

Functional:

• Users can create accounts, add profiles, and update details.
• Users can follow/unfollow other users.
• Users can post content (text, images, videos).
• Users can like, comment, and share posts.
• Users receive real-time notifications (new followers, likes, mentions, comments, etc.).
• Users can search for other users or content.
• A feed shows relevant content based on friends, follows, and recommendations.

Non-Functional:

• System should support millions of concurrent users.
• Low latency: API response times should be < 200ms.
• Scalability: Should handle rapid spikes in traffic.
• Availability: 99.99% uptime.
• Security: User authentication with OAuth (Google, Facebook, Twitter).
• Data consistency: Eventual consistency for high availability.

Capacity Estimation

• Users: Assume 100 million users, with 10% active daily.
• Posts: 10 million posts per day.
• Average post size = 500KB.
• Total storage needed = 5 TB/day.
• Likes and Comments: 50 million likes/comments per day (each 100 bytes).
• Total metadata storage per year = 1.8 TB.
• API Requests: 20 API calls per user per day.
• Peak load = 200K requests per second.

Sure! Here's the rest of the article formatted in Markdown:

---

API Design

API Endpoints

Functionality	API Endpoint	Method
User Signup/Login	/api/auth/signup	POST
Get User Profile	/api/users/user_id	GET
Follow User	/api/users/user_id/follow	POST
Create Post	/api/posts	POST
Get Feed	/api/feed	GET
Like Post	/api/posts/post_id/like	POST
Comment on Post	/api/posts/post_id/comment	POST
Search Users	/api/search	GET

---

Database Design

Entities / Tables:

• Users
• Friendships
• Posts
• Likes

Relationships between Entities:

• Users ↔ Friendships (Many-to-Many) – Users can have multiple friends.
• Users ↔ Posts (One-to-Many) – A user can create multiple posts.
• Users ↔ Likes (Many-to-Many) – A user can like multiple posts.
• Posts ↔ Likes (One-to-Many) – A post can have multiple likes.

Primary and Foreign Keys:

Primary Keys (PK)

• users.user_id
• posts.post_id

Foreign Keys (FK)

• friendships.user1_id → users.user_id
• friendships.user2_id → users.user_id
• posts.user_id → users.user_id
• likes.user_id → users.user_id
• likes.post_id → posts.post_id

SQL Table Definitions:

CREATE TABLE users (
    user_id STRING PRIMARY KEY,
    name STRING,
    email STRING,
    profile_image STRING,
    created_at TIMESTAMP
);

CREATE TABLE friendships (
    user1_id STRING,
    user2_id STRING,
    status STRING,  -- 'pending', 'accepted'
    friendship_strength INT,  -- 1 (Weak), 2 (Medium), 3 (Strong)
    created_at TIMESTAMP
);

CREATE TABLE posts (
    post_id STRING PRIMARY KEY,
    user_id STRING,
    content STRING,
    media_url STRING,
    created_at TIMESTAMP
);

CREATE TABLE likes (
    user_id STRING,
    post_id STRING,
    created_at TIMESTAMP
);

Example Data

INSERT INTO users (user_id, name, email, profile_image, created_at) VALUES
('U1', 'Alice', 'alice@example.com', 'alice.jpg', CURRENT_TIMESTAMP),
('U2', 'Bob', 'bob@example.com', 'bob.jpg', CURRENT_TIMESTAMP),
('U3', 'Charlie', 'charlie@example.com', 'charlie.jpg', CURRENT_TIMESTAMP);

INSERT INTO friendships (user1_id, user2_id, status, friendship_strength, created_at) VALUES
('U1', 'U2', 'accepted', 3, CURRENT_TIMESTAMP),
('U1', 'U3', 'accepted', 2, CURRENT_TIMESTAMP);

INSERT INTO posts (post_id, user_id, content, media_url, created_at) VALUES
('P1', 'U1', 'Excited to join this network!', 'post1.jpg', CURRENT_TIMESTAMP),
('P2', 'U2', 'Loving SALSA recommendations!', 'post2.jpg', CURRENT_TIMESTAMP);

INSERT INTO likes (user_id, post_id, created_at) VALUES
('U1', 'P2', CURRENT_TIMESTAMP),
('U2', 'P1', CURRENT_TIMESTAMP);

---

High-Level Design

System Goals:

• User interactions: Posting, following, liking, commenting.
• Efficient data retrieval: Feeds and recommendations.
• Graph-based friend suggestions: SALSA-based recommendation engine.
• Real-time notifications and event-driven processing.

Core Components and Their Purpose:

Component	Purpose
API Gateway	Routes requests, handles authentication & rate-limiting.
Authentication (Cognito)	Manages user authentication & authorization.
User Service	Manages user profiles, following/unfollowing logic.
Post Service	Handles post creation.
Feed Service	Generates personalized user feeds using caching & ranking models.
Recommendation Service	Uses SALSA-based graph processing for friend suggestions.
Notification Service	Sends real-time push notifications for interactions.
Storage Layer (RDS + DynamoDB)	Stores structured and unstructured data.
ElastiCache (Redis)	Caches feeds for quick retrieval.
BigQuery & Graph DB (Neptune)	Processes social graph queries and recommendations.
Event-Driven Architecture (SNS, SQS, Kinesis)	Ensures async processing for high performance.

---

Request Flows

1. User Signup & Authentication Flow

Scenario: A user signs up and logs in.

Request Flow:

1. User submits credentials → POST /api/auth/signup
2. API Gateway forwards request to AuthService.
3. AuthService validates credentials using Cognito.
4. If valid, Cognito generates JWT token and returns it to AuthService.
5. AuthService sends JWT back to API Gateway.
6. User receives authentication token and can now make further requests.

2. User Posts a New Message

Scenario: A user creates a new post.

Request Flow:

1. User submits post request → POST /api/posts
2. API Gateway forwards request to PostService.
3. PostService stores metadata in RDS (PostgreSQL).
4. If media is attached, PostService uploads it to S3.
5. PostService sends an event to FeedService to update the user’s timeline.
6. PostService triggers SNS notifications to notify followers.

3. User Retrieves Their Feed

Scenario: A user fetches their personalized timeline.

Request Flow:

1. User requests feed → GET /api/feed
2. API Gateway forwards request to FeedService.
3. FeedService checks ElastiCache (Redis) for cached feed.
4. If cache hit, return feed instantly.
5. If cache miss, query DynamoDB for recent posts from followed users.
6. FeedService ranks the feed using BigQuery (Engagement Data).
7. Feed is returned and stored in ElastiCache for faster retrieval.

4. Friend Recommendation Flow (Using SALSA Algorithm)

Scenario: System recommends friends to a user.

Request Flow:

1. User requests friend suggestions → GET /api/recommendations
2. API Gateway forwards request to RecommendationService.
3. RecommendationService queries BigQuery to compute SALSA-based recommendations.
4. BigQuery analyzes mutual friends, engagement, and bipartite graph structure.
5. RecommendationService returns ranked friend suggestions.

Summary of Request Flows

Flow	Key Steps
Signup/Login	Cognito validates user, returns JWT.
Create Post	Post stored in RDS, media uploaded to S3, followers notified via SNS.
Fetch Feed	Check Redis cache, fetch missing posts, rank using BigQuery.
Friend Recommendations	BigQuery computes suggestions using the SALSA algorithm.

Here's the detailed component design formatted in Markdown:

---

Detailed Component Design

Feed Service: Caching & Ranking

Overview

• The Feed Service is responsible for generating and delivering a personalized timeline for users.
• It fetches posts from followed users, ranks them, and caches results for fast retrieval.
• Uses Redis (ElastiCache) for caching and BigQuery for ranking.

How the Feed Service Works

1. User Requests Feed → API Gateway forwards request to FeedService.
2. Check Cache (Redis) for Feed:

• If cache hit → Return cached feed instantly.
• If cache miss → Query DynamoDB for latest posts from followed users.

3. Rank Feed Using BigQuery:

• Fetch engagement data (likes, comments, shares).
• Apply ranking algorithm to order posts.

4. Cache the Ranked Feed in Redis for future requests.

Scaling Considerations

• Read-heavy system → Caching (Redis) reduces database load.
• Frequent updates → TTL (Time-To-Live) of 30 seconds ensures freshness.

Scaling Solution

• Shard Redis by user ID → Distributes load.
• Use a write-through cache → Cache updates when a new post is created.

Recommendation Service: Friend Suggestions using SALSA

Overview

• The Recommendation Service suggests new friends to users.
• Uses SALSA (Stochastic Approach for Link-Structure Analysis) to rank friend suggestions.
• Implements graph traversal over user-follow relationships.

How the Recommendation Service Works

1. User Requests Recommendations → API Gateway forwards request to RecommendationService.
2. Fetch Mutual Friends Data from BigQuery.
3. Run SALSA Algorithm:

• Perform two-step random walk from the user.
• Alternate between “hubs” (followers) and “authorities” (followed users).
• Compute ranking scores based on visit frequency.

4. Return Friend Suggestions.

Scaling Considerations

• BigQuery runs in parallel → Handles millions of social connections efficiently.
• Batch processing recommendations every few hours → Avoids unnecessary recomputation.
• GraphDB (Amazon Neptune) as an alternative for real-time recommendations.

Real-Time Engagement Tracking with AWS Kinesis

Overview

• Tracks user engagement in real-time (likes, comments, shares).
• Uses AWS Kinesis to capture streams of interactions.
• Processes data with BigQuery to update rankings dynamically.

How the Real-Time Tracking Works

1. User interacts with a post (like/comment/share) → API Gateway forwards event.
2. Kinesis captures event stream.
3. Lambda processes events and stores them in Redshift.
4. BigQuery aggregates engagement metrics.
5. Feed rankings update dynamically.

Scaling Considerations

• Kinesis scales automatically → Handles millions of events per second.
• Partitioning by post ID ensures efficient event ingestion.
• Aggregating data in Redshift & BigQuery keeps computation fast.

---

Summary of Detailed Components

Component	Key Features	Scaling Considerations
Feed Service	Caching (Redis), Post Ranking (BigQuery)	Sharding Redis, Expiring Cache (TTL)
Recommendation Service	SALSA Algorithm for Friend Suggestions	BigQuery Batch Processing, GraphDB for Real-Time
Real-Time Tracking	Kinesis for event streaming	Kinesis Partitioning, Redshift Aggregation

---

Trade-offs & Tech Choices

SQL (PostgreSQL) vs. NoSQL (DynamoDB)

Option	Why Consider It?	Final Choice & Reasoning
PostgreSQL (RDS)	Relational, ACID-compliant, supports complex queries	Chosen for structured data (users, posts, friendships). Supports JOINS, transactions, and consistency.
DynamoDB (NoSQL)	High-speed key-value lookups, good for caching-style operations	Used for fast lookups (likes, quick user interactions) where JOINS aren’t required.
Hybrid Approach	Use both SQL (structured) & NoSQL (unstructured)	Best of both worlds: SQL for structured social graphs, NoSQL for high-speed reads.

Trade-Off

• PostgreSQL is slower for read-heavy workloads compared to DynamoDB.
• DynamoDB lacks relational querying, making recommendations more difficult.
• Solution → Hybrid approach ensures optimal performance (RDS for complex queries, DynamoDB for real-time interactions).

---

Redis Caching vs. Querying Database for Feeds

Option	Why Consider It?	Final Choice & Reasoning
Fetch feed from PostgreSQL/DynamoDB	Always up-to-date but slower due to multiple DB queries	Too slow for real-time feed rendering.
Redis Cache (ElastiCache)	Speeds up retrieval by storing precomputed feeds	Best for low-latency feed delivery. Store top 50 posts per user in Redis.
Hybrid Approach	Store precomputed feeds but periodically refresh from DB	Chosen approach: Redis stores feeds, DB updates the cache every few minutes.

Trade-Off

• Redis is fast but requires managing cache expiration (TTL = 30s).
• Direct DB queries are fresh but slow.
• Solution → Combine both:
• Cache recent feeds for instant access.
• Trigger DB refresh when a new post is added.

---

SALSA Algorithm vs. PageRank for Recommendations

Option	Why Consider It?	Final Choice & Reasoning
PageRank (Google’s Algorithm)	Ranks users based on total incoming links	Too biased toward high-follower users (celebrities dominate suggestions).
SALSA (Stochastic Approach for Link-Structure Analysis)	Uses bipartite graphs (hubs & authorities) for better recommendations	Best for Twitter-style friend suggestions (finds users similar to those you follow).
Hybrid Approach	Mix SALSA with content-based ranking	SALSA for social graph, BigQuery ML for behavioral insights.

Trade-Off

• SALSA is better for mutual connections but doesn’t account for engagement (likes, comments).
• PageRank is better for global rankings but favors influencers.
• Solution → SALSA + Engagement-Based ML for Hybrid Recommendations.

---

BigQuery vs. AWS Neptune (Graph DB)

| Option | Why Consider It? | Final Choice & Reasoning | |-----------------|---------------------|------------------------------| | AWS Neptune (Graph Database) | Purpose-built for social graph analysis | Harder to scale beyond graph queries. | | BigQuery (Data Warehouse for Analytics) | Works well with batch processing, scaling | Best for large-scale friend recommendations. | | Hybrid Approach | Use BigQuery for batch processing & GraphDB for real-time queries | GraphDB for real-time, BigQuery for large-scale batch ranking. |

Trade-Off

• BigQuery handles billions of rows but isn’t real-time.
• AWS Neptune is faster but harder to query at scale.
• Solution → BigQuery for batch processing, GraphDB for real-time analysis.

---

Kinesis vs. Kafka for Real-Time Events

Option	Why Consider It?	Final Choice & Reasoning
AWS Neptune (Graph Database)	Purpose-built for social graph analysis	Harder to scale beyond graph queries.
BigQuery (Data Warehouse for Analytics)	Works well with batch processing, scaling	Best for large-scale friend recommendations.
Hybrid Approach	Use BigQuery for batch processing & GraphDB for real-time queries	GraphDB for real-time, BigQuery for large-scale batch ranking.

Trade-Off

• Kafka gives more control but requires manual scaling.
• Kinesis is auto-scaled but tied to AWS.
• Solution → Use Kinesis for real-time tracking of user engagement.

Here is your Failure Scenarios & Bottlenecks section formatted in Markdown:

---

Failure Scenarios & Bottlenecks

A scalable social network must be fault-tolerant, highly available, and resilient to failures. Below we discuss potential failure scenarios, their impact, and solutions.

---

Database Bottlenecks & Failures

Problem: High Read/Write Load on PostgreSQL (RDS)

• Issue: When millions of users interact with the platform, relational database queries slow down.
• Impact: Slower user profile retrieval, delayed posts, and failed transactions.
• Solution:
• Use Read Replicas → Offload reads from the main database.
• Cache user profiles and posts in Redis to avoid frequent database queries.
• Use DynamoDB for high-speed lookups (likes, recent activity).
• Partition database tables (shard by user_id) to distribute load.

Problem: Single Point of Failure in RDS

• Issue: If the primary PostgreSQL database crashes, the system goes down.
• Impact: Users cannot post, view feeds, or interact.
• Solution:
• Enable Multi-AZ (Availability Zones) for RDS → Automatic failover to a backup instance.
• Use periodic database backups & point-in-time recovery to restore data quickly.

---

Cache Invalidation Issues

Problem: Stale Feed Data in Redis

• Issue: The feed stored in Redis may become outdated, leading to users seeing old posts.
• Impact: Users miss new posts, leading to frustration.
• Solution:
• Set a short TTL (Time-To-Live) for cache (e.g., 30 seconds).
• Use event-driven updates (e.g., when a new post is created, update Redis immediately).

Hybrid Cache Strategy

• Write-through caching → Store data in Redis first, then update the database.
• Write-back caching → Update the database in the background asynchronously.

Problem: Redis Overload

• Issue: Redis can become overloaded due to excessive cache writes/reads.
• Impact: The entire cache layer crashes, increasing database load.
• Solution:
• Implement cache eviction policies (Least Recently Used – LRU).
• Shard Redis by user ID to distribute load across multiple Redis clusters.
• Set memory limits and monitor cache hit rates.

---

Real-Time Event Processing Failures

Problem: Kinesis Fails to Process Engagement Data

• Issue: If AWS Kinesis goes down or lags, engagement tracking (likes, comments, shares) stops.
• Impact: SALSA recommendations become outdated, and trending post ranking fails.
• Solution:
• Use AWS SQS as a backup queue → If Kinesis is unavailable, route events to SQS for delayed processing.
• Enable Kinesis Auto-Scaling to handle traffic spikes dynamically.

---

Recommendation System Issues

Problem: SALSA Algorithm Generates Poor Recommendations

• Issue: If SALSA has insufficient user data, it may suggest irrelevant friends.
• Impact: Users get low-quality friend recommendations, leading to disengagement.
• Solution:
• Combine SALSA with engagement-based ranking (likes, shares).
• Use BigQuery ML to fine-tune recommendations based on historical user behavior.
• Periodically re-train models to ensure freshness.

---

API Gateway & Authentication Failures

Problem: API Gateway Rate Limits too Strict

• Issue: If API rate limits are too aggressive, normal users get blocked.
• Impact: Users see errors when trying to access the platform.
• Solution:
• Implement dynamic rate limiting (e.g., adjust based on user activity patterns).
• Allow temporary rate limit increases for VIP users or verified accounts.

Problem: Cognito Authentication Outage

• Issue: If AWS Cognito fails, no user can log in.
• Impact: Complete system lockout.
• Solution:
• Use a fallback authentication provider (e.g., Firebase Auth) in case Cognito is down.
• Cache authentication tokens in Redis to allow temporary login even if Cognito is down.

---

Traffic Spikes & Scaling Bottlenecks

Problem: Unexpected Traffic Spike

• Issue: A viral post or high-profile user joins and generates 10x normal traffic.
• Impact: Database overload, API latency increases, users face downtime.
• Solution:
• Use Auto-Scaling Groups (ASG) in AWS to increase compute power dynamically.
• Distribute requests across multiple regions (CDN for images, global load balancing).
• Enable Redis + CDN caching for high-traffic endpoints.

---

Security & Data Privacy Risks

Problem: User Data Breach

• Issue: If a vulnerability exposes user data, attackers can steal profiles, messages.
• Impact: Reputation damage, legal issues.
• Solution:
• Encrypt user data at rest (AWS KMS) and in transit (HTTPS/TLS).
• Use IAM roles with least privilege access.
• Monitor logs with AWS CloudTrail for suspicious activity.

---

Summary of Failure Scenarios & Solutions

Failure	Impact	Solution
DB Overload	Slow response times	Use read replicas, sharding, Redis caching.
Cache Invalidation Issues	Stale feed data	Use TTL-based caching, event-driven updates.
Kinesis Failure	Engagement tracking stops	Use SQS fallback, auto-scaling.
Weak Friend Recommendations	Low engagement	Combine SALSA + ML-based ranking.
API Gateway Rate Limits	Blocks legit users	Use adaptive rate limiting.
Authentication Failure (Cognito)	No logins possible	Use backup auth provider, cache JWT tokens.
Traffic Spike Overload	System crash	Auto-scaling, CDN, cache optimizations.
Security Breach	Data theft	Encryption, IAM restrictions, monitoring.

---