Mir Shahriar Sabuj

The supply service's responsibility is to find the best candidate to fulfill a request for a ride, food delivery, or any other service. In the initial version, this service saved all data in Elasticsearch, resulting in discrepancies and delayed search results when there was a high volume of requests. After that, we concluded that the architecture needed to be altered. Hence, we added Redis for caching, Elasticsearch for location pings, and MySQL for metadata about the drivers.

I oversaw the team in developing the new features and enhancing performance.

The supply service can now manage almost twice as much traffic as before. The new architecture makes it much easier to incorporate new features, such as preferred destination, advance dispatch, and area slotting, into an existing system.

Pathao is a ride-sharing platform, so reasonable pricing is essential to a good user experience on the platform. Initially, Pathao utilized a base fare with an adjustable charge. The shifting supply and demand curve did not affect the pricing.

I began working on this project to find a solution to the problem. I came up with a statistical model. Among other aspects, supply and demand statistics are used to calculate the surge fare. It gathers supporting information from events and stores it in InfluxDB for aggregation. In this project, the fare is calculated, and polygons are created for the client application.

This solution raises the total acceptance rate while simultaneously reducing the percentage of system cancellations by 15%. Additionally, it gives driver applications a dynamic pricing representation.

The number of organizations using Kubernetes continued to rise. On the other hand, database management within Kubernetes proved to be exceedingly challenging. Managing a database requires several responsibilities, including provisioning, scalability, backups, and more. As of 2016, there was no commercially available solution for managing database operations within Kubernetes.

We then developed the KubeDB concept. KubeDB is a CRD controller that streamlines the process of provisioning various databases within Kubernetes. It simplifies and automates routine database tasks such as provisioning, patching, backup, recovery, failure detection, and repair for different popular databases.

KubeDB provides many familiar database engines, including PostgreSQL, MySQL, MongoDB, Elasticsearch, Redis, and Memcached.

Continuous communication is critical in ridesharing and food delivery. Before this project, clients communicated primarily through cell phone calls, which was expensive and time-consuming. This process, in some cases, increased user cancellation. The In-App chat platform enables clients to communicate frequently and seamlessly. It also makes the confirmation process faster by using pre-set messages. This service supports sharing audio clips, which boosts the user experience.

We have used WebSocket and intend to switch to gRPC. We store historical data in GCS for future reference.

Users running production workloads in Kubernetes will likely want to be notified if something goes wrong. Icinga2 performs periodic checks on a Kubernetes cluster and sends alerts if it detects a problem. It also complements Whitebox monitoring tools such as Prometheus with Blackbox monitoring, which can detect problems that are otherwise undetectable and serves as a backup if the internal systems fail. Searchlight is a Kubernetes CRD controller based on Icinga that addresses these issues. This service is capable of notifying users via email, SMS, or chat and managing acknowledgments.