Designing Content Delivery Network (CDN) in System Design

A CDN (Content Delivery Network) is a network of globally distributed servers that stores and delivers website/app content like images, videos, CSS, JS, and files from the nearest edge server, so users get faster load time, lower latency, and better availability, while the main origin server load also reduces.

• Reduces latency by serving content from the nearest edge server.
• Improves performance with faster load times and better user experience.
• Enhances availability and scalability by handling traffic spikes and failures.

Example: When a user in India opens a website hosted in the US, the CDN delivers images and files from a nearby server (e.g., Mumbai), making the website load much faster.

1. Working

In a Content Delivery Network, the origin server contains the original version and the edge servers are distributed across various location around the world.

Step by step process of how CDN's work:

• User sends a request for content (e.g., an image) from a website.
• CDN identifies the user's location and routes the request to the nearest edge server.
• If the content is cached at the edge server, it is delivered directly to the user.
• If the content is not cached, the edge server retrieves it from the origin server, caches it locally, and delivers it to the user.
• Cached content is stored at the edge server for future requests, optimizing performance and reducing latency.

Example: suppose when there is someone in Canada request on our website which might be hosted in USA, they will be served from the closest edge location such as the London edge location. This much quicker than having the visitor make a complete request to the origin server which will increase the latency.

2. System Requirements

A CDN must support both functional and non-functional needs.

1. Functional Requirements

This section describes the core features required for a CDN system.

• Content Distribution: Replicate and sync content globally
• Caching: Cache static and handle dynamic content efficiently
• Load Balancing: Distribute requests using load balancing algorithms
• Content Purge: Invalidate outdated cached content quickly

2. Non-Functional Requirements

This section defines system qualities like performance, scalability, and reliability.

• Scalability: Add more servers as traffic grows
• Reliability: High availability using redundancy and failover
• Global Load Balancing: Route requests using geo/anycast routing
• Content Optimization: Compression, minification, image optimization
• Mobile Optimization: Adaptive delivery for mobile device

3. Capacity Estimation

You can estimate the system capacity by analyzing certain data like traffic, number of user coming on site, storage requirements, etc. By analyzing whole data we can further calculate the required storage capacity for whole year. Here is the simplified calculation given:

Traffic is 50,000 vistors per month

Traffic per second = 50000/30*24*60*60
= 0.019

Assumption: 40% of requests served by CDN
20% of static content

CDN static TPS = 0.019×40%×20% = 0.019×0.40×0.20
= 0.00152 requests/sec

Storage required (approx 200kb/file size) = 0.00152*200 = 0.304 KB/S
Storage required per year = 0.304×60×60×24×365 = 9.14 GB/year

4. Uses Case Diagram

It shows how users request content, the CDN caches and delivers it via edge servers, while the content provider uploads and manages content.

Explanation of Diagram

This diagram illustrates how different actors interact with the CDN system to deliver content efficiently.

User (End User): The user initiates the process by requesting content (such as images, videos, or web pages) through their browser. The CDN processes this request and delivers the content back to the user with low latency and high performance.

Content Provider: The content provider uploads content (e.g., media files, website assets) to the CDN and configures settings like caching rules and distribution policies. This ensures content is properly stored and optimized for delivery.

CDN System: The CDN acts as the core system that handles all operations related to content delivery. When a request is received, the CDN first checks if the content is available in cache. If available, it serves the content directly; otherwise, it fetches it from the origin server, caches it, and then delivers it to the user.

Cache Content: This is a mandatory step where the CDN stores frequently accessed content in edge servers to reduce latency and improve performance.

Distribute Content: The CDN distributes content to users based on their geographic location, ensuring faster delivery.

Load Balancing: Requests are distributed across multiple servers to avoid overload and ensure efficient resource utilization.

Upload Content & Configure CDN: These are optional actions performed by content providers to manage and customize how content is delivered through the CDN.

Overall, the diagram shows how the CDN ensures fast, scalable, and reliable content delivery by combining caching, load balancing, and intelligent traffic management.

5. Low-Level Design

Low-level design involves unique specifications for each thing of the CDN. It interprets high level design right into a greater granular blueprint, providing a guide for developers to put into effect individual modules.

Low-level design focuses on internal modules.

• Caching Module: TTL caching, cache miss handling, eviction policy (LRU/FIFO).
• Load Balancing Module: Round robin, least connections, weighted routing.
• Security Module: HTTPS, DDoS protection, rate limiting, access control.
• Content Delivery Module: Origin fetch, edge sync, consistent delivery.

6. High Level Design

High-level design presents an architectural evaluation of the CDN. It makes a speciality of the interplay among important additives and the general flow of data.

1. Edge Server

In the High-Level Design (HLD), the structure of the Content Delivery Network (CDN) is printed with a focus at the distribution of edge servers globally.

Role:

This defines how edge servers improve performance and handle user requests.

• Edge servers are strategically placed in diverse geographic locations to make certain proximity to give up end-customers, thereby minimizing latency.
• The design emphasizes the load balancing mechanism, detailing how incoming requests are successfully disbursed amongst those aspect servers.
• The average purpose is to create a scalable and responsive network that complements the shipping of web content.

2. Origin Server Interaction

The HLD presents perception into how part servers interact with the starting place server. It outlines the procedure of content material retrieval from the origin server and how updates are propagated at some point of the CDN.

Role:

This defines how content is fetched, updated, and kept available.

• Strategies for minimizing latency in content material updates are highlighted, making sure that users acquire the maximum recent content successfully.
• The design additionally addresses failover mechanisms and backup strategies to assure continuous content material availability even inside the face of origin server screw ups.

3. CDN Controller

Introducing a central controller, the HLD elaborates on the control and coordination of edge servers.

Role:

This defines how the CDN controller manages and optimizes the network.

• The CDN controller acts as the orchestrator, overseeing the overall functionality of the CDN.
• It communicates with individual edge servers, conveying configuration adjustments, monitoring health status, and facilitating global traffic management.
• The design emphasizes the scalability of the CDN controller, making sure it could deal with the developing needs of an increasing community.

7. Database Design

A CDN database stores content metadata, edge server info, cache status, and request logs to manage fast delivery and monitoring.

Content Table: This table stores information about the content served by the CDN, including its type, location, and size.

Content_id: Unique identifier for each piece of content.
Content_name: Descriptive name or title of the content.
Content_type: Indicates the type of content (e.g., image, video, script).
Content_url: URL or path to the content on the CDN.
Content_size: Size of the content file.
Last_updated: Timestamp indicating when the content was last updated.

Edge Server Table: This table represents the edge servers in the CDN, including their location, capacity, current load, and operational status.

Server_id: Unique identifier for each edge server.
Server_location: Geographical location of the edge server.
Server_capacity: Capacity or resources of the server (CPU, RAM, storage).
Current_load: Current load or usage on the server.
Status: Operational status of the server (active, standby, offline).

User Request Table: This table logs user requests, recording details such as user ID, requested content, the edge server used, and response time.

Request_id: Unique identifier for each user request.
User_id: ID of the user making the request.
Content_id: ID of the requested content.
Request_timestamp: Timestamp indicating when the request was made.
Edge_server_used: ID of the edge server that fulfilled the request.
Response_time: Time taken to fulfill the request.

Traffic Log Table: This table stores logs related to CDN activities, providing insights into different types of requests and events.

Log_id: Unique identifier for each log entry.
Timestamp: Timestamp indicating when the log entry was created.
Request_type: Type of request (content retrieval, cache purge, etc.).
Details: Additional details about the request or event.

Cache Table: This table manages the caching information, including content ID, edge server ID, expiration details, and cache status.

Cache_id: Unique identifier for each cache entry.
Content_id: ID of the content being cached.
Edge_server_id: ID of the edge server where the content is cached.
Expiration_timestamp: Timestamp indicating when the cached content expires.
Cache_status: Status of the cache (valid, expired, purged).

8. API used

APIs are used to add, fetch, update, and purge content so edge servers can cache and deliver data faster.

API Code Implementation

It defines backend endpoints to manage CDN content operations like add, fetch, update, and purge cache.

Add New Content API (POST) Request:

• Endpoint:/api/content
• Description: Allows administrators to add new content to the CDN.

Retrieve Content Details API (GET) Request:

• Endpoint:/api/content/c12345
• Description: Retrieves details of a specific content item from the CDN.

Update Content API (PUT) Request:

• Endpoint:/api/content/c12345
• Description: Allows administrators to update details of existing content in the CDN.

9. Microservices used

Edge Service, Load Balancer Service, Security Service, and Analytics Service work together to cache, route, protect, and monitor content delivery.

1. Edge Service

The Edge Service in the Microservices and APIs Used section of the design specializes in dealing with content caching, retrieval, and delivery.

• The layout specifies the API for conversation with the CDN controller, making an allowance for seamless coordination.
• The edge provider microservice is accountable for dealing with content material at the edge servers, making sure efficient caching strategies, and responding to user requests with minimal latency.

2. Load Balancer Service

This microservice is devoted to load balancing and distributing incoming requests among area servers.

• The layout elaborates at the APIs exposed by the Load Balancer Service, detailing the way it dynamically adjusts the distribution of traffic based totally on server health and different metrics.
• The microservice guarantees even usage of resources and prevents any single server from becoming a bottleneck.

3. Security Service

The Security Service microservice is responsible for imposing security features together with DDoS safety and access controls.

• The layout outlines the APIs used for validating and authorizing requests, ensuring that the CDN keeps a secure environment for content delivery.
• It specializes in the modularity of security functions to permit for destiny enhancements or adjustments.

4. Analytics Service

The Analytics Service microservice is designed to collect and procedure overall performance metrics.

• The design specifies the APIs for gaining access to analytics information, taking into consideration real-time tracking and evaluation of CDN performance.
• This microservice contributes to statistics-driven selection-making, enabling continuous optimization and upgrades in content material delivery.

10. Scalability used

Scalability ensures CDN works under heavy load.

1. Horizontal Scaling

This section explains how the system scales by adding more servers to handle increased traffic.

• The Scalability section of the design focuses on the strategies employed for horizontal scaling.
• It outlines mechanisms for dynamically adding more aspect servers to the CDN to address elevated traffic masses.
• The layout emphasizes the importance of load balancing in dispensing requests evenly throughout these servers, ensuring optimal resource utilization.

2. Vertical Scaling

This section explains scaling by upgrading existing server resources.

• Vertical Scaling is addressed by way of specifying how individual servers can be upgraded to deal with  higher loads.
• The design outlines auto-scaling mechanisms that dynamically adjust sources (CPU, RAM) primarily based on demand.
• This ensures that the CDN can adapt to varying levels of site visitors without sacrificing overall performance.

3. Stateless Design

This section describes how stateless architecture improves scalability.

• The design emphasizes the significance of a stateless layout to obtain seamless scalability.
• Stateless structure allows any edge server to handle any consumer request with out counting on session-precise statistics stored domestically.
• This design choice allows flexibility in adding or removing of servers without impacting user sessions, contributing to the overall scalability of the CDN.