Mobile System Design and API Design of Ride-hailing Mobile App
Explore the design of a ride-hailing mobile app focusing on a layered MVVM-C architecture, Backend for Frontend (BFF) integration, and optimized API design. Understand how to manage real-time GPS data, network latency, and fault-tolerant transactions while maintaining UI responsiveness under varying network conditions. This lesson helps you build scalable, efficient mobile systems for ride request, active trip tracking, and fare estimation workflows.
A user requesting a ride triggers a massive, distributed cascade of events, but on their screen, the experience must feel instantaneous and entirely local. The theoretical decisions made in the previous lesson, such as adopting MVVM-C for UI isolation and using dependency injection for testability, must now be wired together into a concrete data pipeline.
This lesson details the end-to-end System Design of the mobile ride-hailing client. We will trace the data flow from the user's touch down to the network layer, establish the role of the
System Design of a ride-hailing mobile app
To manage concurrent real-time GPS streams and network disruptions, the mobile client requires strict structural organization. A flat architecture leads to tightly coupled view controllers that handle WebSocket reconnects and map marker updates simultaneously, increasing maintenance complexity and runtime errors.
Instead, the system enforces strict boundaries. The UI focuses purely on rendering data, domain logic is isolated from network execution, and local caching mitigates latency. This separation ensures that when a user requests a ride in a low-connectivity zone, the application remains responsive while the underlying layers manage dispatch requests and state synchronization.
Let’s first discuss a high-level System Design to establish a solid architectural overview.
High-level design
Data enters and exits the ride-hailing app through a defined hierarchy. The UI (View) does not interact with the network or the database directly. When a user action occurs, the View delegates the interaction to the ViewModel, which in turn queries a Repository.
The repository acts as the primary data routing component. It checks local caches for immediate data retrieval, such as static fare boundaries or the last known trip state, before ...