Designing Uber Ride-Hailing Service

Disclaimer: All content below is sourced from public resources or purely original. No confidential information regarding Uber is included here.

Requirements

uber architecture

==Conway's Law== The structure of a software system corresponds to the organizational structure of the company.

	Monolithic ==Service==	Microservices
When team size and codebase are small, productivity	✅ High	❌ Low
==When team size and codebase are large, productivity==	❌ Low	✅ High (Conway's Law)
==Quality requirements for engineering==	❌ High (Inadequately skilled developers can easily disrupt the entire system)	✅ Low (Runtime is isolated)
Dependency version upgrades	✅ Fast (Centralized management)	❌ Slow
Multi-tenant support / Production-staging state isolation	✅ Easy	❌ Difficult (Each service must 1) either establish a staging environment connected to other services in staging 2) or support multi-tenancy across request contexts and data storage)
Debuggability, assuming the same modules, parameters, logs	❌ Low	✅ High (if distributed tracing is available)
Latency	✅ Low (Local)	❌ High (Remote)
DevOps costs	✅ Low (High cost of build tools)	❌ High (Capacity planning is difficult)

Combining monolithic ==codebase== and microservices can leverage the strengths of both.

==The key is to have asynchronous design==, as ACID transaction payment systems across multiple systems often have very long latencies.

Use caching to reduce latency
As 1) support for more countries and regions increases 2) user roles (drivers, riders, restaurant owners, diners, etc.) gradually expand, providing user profile services for these users also faces significant challenges.