System Overview - Availability checking
This system checks if a resource (like a product, room, or service) is available for booking or use. It must respond quickly and handle many users checking availability at the same time without errors.
0
0
Availability checking in LLD - Architecture Diagram
Architecture Diagram
User | v Load Balancer | v API Gateway | v Availability Service | +-----> Cache | v Database
Components
User
client
Sends availability check requests
Load Balancer
load_balancer
Distributes incoming requests evenly to API Gateway instances
API Gateway
api_gateway
Receives requests, handles authentication and routing to services
Availability Service
service
Processes availability check logic, queries cache and database
Cache
cache
Stores recent availability results for fast response
Database
database
Stores authoritative availability data
Request Flow - 11 Hops
User → Load Balancer
Load Balancer → API Gateway
API Gateway → Availability Service
Availability Service → Cache
Cache → Availability Service
Availability Service → Database
Database → Availability Service
Availability Service → Cache
Availability Service → API Gateway
API Gateway → Load Balancer
Load Balancer → User
Failure Scenario
Component Fails:Cache
Impact:Availability Service cannot get fast cached data, causing slower responses as it queries the database directly.
Mitigation:System continues working by querying the database; cache can be rebuilt asynchronously. Adding cache replication or fallback caches can improve resilience.
Architecture Quiz - 3 Questions
Test your understanding
Which component first receives the user's availability check request?
Design Principle
This design uses a cache to speed up availability checks and reduce database load. The load balancer and API gateway ensure requests are distributed and managed securely. The system gracefully handles cache failures by falling back to the database, ensuring availability and reliability.