0
0
Microservicessystem_design~12 mins

Uber architecture overview in Microservices - Architecture Diagram

Choose your learning style9 modes available
LearnWhyDeepArchPracticeChallengeDesignRecallScale
System Overview - Uber architecture overview

Uber is a ride-hailing platform that connects riders with drivers in real time. It requires handling high volumes of location data, trip requests, and payments with low latency and high availability.

Key requirements include real-time matching, scalable microservices, fault tolerance, and data consistency across services.

Architecture Diagram
User
  |
  v
Load Balancer
  |
  v
API Gateway
  |
  +-----------------------------+
  |                             |
  v                             v
Matching Service           Trip Management Service
  |                             |
  v                             v
Driver Location Service     Payment Service
  |                             |
  v                             v
Cache (Redis)               Database (PostgreSQL)
  |
  v
Database (Cassandra)
Components
User
client
Riders and drivers using the Uber app
Load Balancer
load_balancer
Distributes incoming requests evenly to API Gateway instances
API Gateway
api_gateway
Routes requests to appropriate microservices and handles authentication
Matching Service
service
Matches riders with nearby drivers in real time
Trip Management Service
service
Manages trip lifecycle including start, progress, and completion
Driver Location Service
service
Tracks and updates driver locations continuously
Payment Service
service
Handles fare calculation, payment processing, and receipts
Cache (Redis)
cache
Stores frequently accessed data like driver locations for fast retrieval
Database (Cassandra)
database
Stores large scale, distributed location and trip data
Database (PostgreSQL)
database
Stores transactional data such as payments and user profiles
Request Flow - 9 Hops
User → Load Balancer
Load Balancer → API Gateway
API Gateway → Matching Service
Matching Service → Cache (Redis)
Cache (Redis) → Matching Service
Matching Service → API Gateway
API Gateway → User
Trip Management Service → Database (Cassandra)
Payment Service → Database (PostgreSQL)
Failure Scenario
Component Fails:Cache (Redis)
Impact:Driver location queries slow down as Matching Service must query database directly, increasing latency
Mitigation:Fallback to database queries with optimized indexes; add cache replication and failover to reduce downtime
Architecture Quiz - 3 Questions
Test your understanding
Which component is responsible for routing user requests to the correct microservice?
AAPI Gateway
BLoad Balancer
CMatching Service
DCache
Design Principle
This architecture uses microservices to separate concerns like matching, trip management, and payments. It employs caching to reduce latency for frequent queries and uses different databases optimized for specific data types. Load balancers and API gateways ensure scalability and secure routing.