Scaling for Success: How Pathao Evolved Its System Design to Serve Millions

Mohammad Sheikh Ghazanfar

9 May, 2025

Founded in 2015, Pathao has grown to become one of the largest and fastest-growing tech startups in Asia, supporting over 15 million registered users across Bangladesh and Nepal. The company operates in over 10 cities, including Dhaka, Chittagong, Kathmandu, Pokhara, and Chitwan. Pathao offers a wide range of services, including ride-sharing, food delivery, e-commerce, and digital payments.

In this article, we will explore how Pathao evolved its system architecture to accommodate its growing user base, scale its services, and meet the demands of an expanding digital ecosystem.

Early Architecture: Building a Foundation for Rapid Launch Pathao’s initial architecture was designed for simplicity and speed, utilizing a stack similar to Facebook’s early setup, using a stack-based on PHP and MySQL. User requests were managed by NGINX, directing traffic to a monolithic application, while Firebase handled real-time functionalities, and MySQL served as the primary database.

This stack was chosen to facilitate a rapid launch by prioritizing:

  1. Functionality Over Complexity: The goal was to create a usable product without the need for an overly complex solution.
  2. Speed of Delivery: A quick release allowed for early user feedback, enabling faster iteration and improvement.
  3. Familiar Stacks: By using well-known technologies, the team was able to develop and deploy efficiently, bypassing the need for a steep learning curve with new tools.

During this period, Pathao’s operations relied heavily on Facebook to engage users and grow its customer base as the platform continued to evolve.

Managing Initial Scaling Pressures As Pathao’s popularity surged, handling over 1,000 daily requests became challenging. The existing monolithic architecture began to show limitations:

  • Scaling Challenges: The monolithic design struggled under the increased load, risking bottlenecks and potential downtime.
  • NGINX Optimization: The team tweaked NGINX configurations to improve load handling, adjusting connection limits, buffering, and load-balancing settings.
  • Vertical Scaling: Pathao upgraded server hardware, increasing CPU, memory, and storage to manage the load without restructuring the architecture.

These adjustments helped Pathao handle initial scaling pressures, but as requests continued to grow, it became clear that further changes were needed for long-term scalability.

Addressing Concurrency Limitations As usage grew, Pathao encountered challenges with handling high volumes of concurrent requests. To improve performance and ensure reliability, the team implemented the following measures:

  1. Horizontal Scaling: Additional servers were introduced to distribute traffic across multiple instances, increasing the platform’s capacity to manage higher request loads effectively.
  2. Read-Write Separation: By directing read and write operations to separate database instances, Pathao optimized database performance, reducing response times and improving throughput.

 

These solutions enabled Pathao to support a higher volume of concurrent users, enhancing the overall user experience as the platform scaled.

Queue and Dispatcher Implementation With 5,000 drivers completing 15,000 rides daily, continuous location pings from drivers’ devices put a strain on the server and database, resulting in race conditions and job-locking issues. To alleviate this, Pathao introduced:

  • Queueing System: By adding queues, Pathao managed location updates efficiently, reducing server load.
  • Dispatcher Service: The dispatcher handled ride allocations, improving ride management and reducing bottlenecks.

This setup streamlined operations and improved reliability, allowing Pathao to better handle high-frequency location updates and ride assignments.

Separating Write-Heavy Traffic Driver location pings, which accounted for over 90% of all traffic, were particularly demanding. With drivers updating their locations more than 10 times per minute, the system faced up to 1,000 requests per second during peak times. To manage this load:

  • Direct Routing to Supply Service: Location pings were routed directly from the mobile app to the Supply service, which stored data in Elasticsearch.
  • Expanding Consumer Services: Pathao introduced additional consumers for tasks such as handling transactions, metadata, and notifications.
  • Support for Internal Tools: Internal reporting and BI tools were integrated, allowing efficient communication with the system.

This restructuring allowed Pathao to manage high-frequency location pings while maintaining service performance.

Introducing Gateways and Redis for Improved Performance To address the needs of a geographically diverse user base in Bangladesh and Nepal, Pathao implemented:

  • Location and Global Gateways: The Location Gateway managed driver pings, while the Global Gateway supported all users, allowing seamless management of requests across regions.
  • Redis for Caching: Redis was introduced to cache frequently accessed data, reducing database load and improving response times.

Additionally, location pings were sent to a tracker service, which filtered and stored relevant data in Elasticsearch, enhancing driver tracking efficiency and supporting real-time updates in the Supply service.

 

Tipping Point: Transition to Microservices and an Evolving Architecture

As Pathao scaled its operations and team, managing a monolithic codebase became increasingly challenging, underscoring the need for a more flexible and scalable system architecture. This shift led to Pathao’s gradual transition to a microservices-based architecture, enabling autonomous teams to work independently and improve service delivery. Key developments included:

  1. Transition to Microservices: Pathao began breaking the monolith into microservices, allowing teams to work independently and deploy services faster.
  2. Kubernetes for Orchestration: Kubernetes was implemented to manage deployments, ensuring efficient resource allocation and service stability.
  3. Event Bus for Inter-Service Communication: An event bus enables seamless communication between services, improving data flow and synchronization.

In the latest iteration, Pathao adopted a more complex microservices architecture to support its expanding feature set:

  1. Google Pub/Sub: This was introduced to handle real-time tracking, promotions, and quests, ensuring efficient message delivery across services.
  2. Core and Order Management Systems: The monolithic codebase was split into Core and Order Management Systems, creating a clear separation of responsibilities.
  3. Microservices for Critical Functions: Key functions like Allocation, ETA, Pricing, and Rating were developed as standalone services, each interacting with the Core system.

This architecture enabled Pathao to support a diverse range of services, optimize resource usage, and deliver a seamless experience for its growing user base across multiple regions.

Pathao’s journey from a simple monolithic application to a scalable, microservices-based architecture illustrates its commitment to supporting millions of users across a wide range of services. By continuously evolving its system design, Pathao has positioned itself as a robust, adaptable platform, capable of meeting the demands of a dynamic and expanding digital ecosystem.

References

Caution: The information provided in this article draws significantly from seminar discussions, which may contain informal insights or estimations. As with any non-verified source, minor inaccuracies may be present. For critical details, direct consultation with official Pathao resources is recommended.

Mohammad Sheikh Ghazanfar

9 May, 2025