Single point of failure identification in HLD - Architecture Diagram

System Overview - Single point of failure identification

This system demonstrates a simple web application architecture. It highlights components where failure can stop the entire system from working, known as single points of failure. The goal is to identify these points and understand their impact and mitigation.

Architecture Diagram

User
  |
  v
Load Balancer
  |
  v
API Gateway
  |
  v
Web Service
  |
  v
Cache
  |
  v
Database

Components

User

client

End user accessing the web application

Load Balancer

load_balancer

Distributes incoming requests to API Gateway instances

API Gateway

api_gateway

Routes requests to backend services and handles authentication

Web Service

service

Processes business logic and interacts with database and cache

Cache

cache

Stores frequently accessed data to reduce database load

Database

database

Stores persistent application data

Request Flow - 10 Hops

User → Load Balancer

Load Balancer → API Gateway

API Gateway → Web Service

Web Service → Cache

Cache → Web Service

Web Service → Database

Database → Web Service

Web Service → API Gateway

API Gateway → Load Balancer

Load Balancer → User

Failure Scenario

Component Fails:Load Balancer

Impact:All incoming user requests fail to reach the API Gateway, causing complete service outage.

Mitigation:Deploy multiple load balancers with failover or use a managed load balancing service to avoid single point of failure.

Architecture Quiz - 3 Questions

Which component is a single point of failure that can block all user requests if it fails?

A Web Service

B Cache

C Load Balancer

D Database

Design Principle

This architecture highlights the importance of identifying components that can cause total system failure if they stop working. Load balancers, as the entry point, are critical and must be made redundant. Caches help reduce load on databases and can serve reads during database outages, improving resilience.