System Design of a Delivery System like Zomato with

Рет қаралды 33,490

Gaurav Sen

Күн бұрын

Пікірлер: 30

@KeertiPurswani 9 ай бұрын

Absolutely love recording this series! The discussions are so raw and real, hope you all are also liking it!

@rishiraj2548 9 ай бұрын

Yes... Great thanks

@rishabhbafna36 9 ай бұрын

12:55 Here in the cache you can store the data in a priority queue like data structure in low level, where the nearest, best rated and fairest top riders let say 10 will get the notification of the order. And If non of them accepts for say 1 minute, than next 10 will be shown. This way we can limit the size of the cache and fetch the top required data from the central db in the memory.

@arunavasaha7051 6 ай бұрын

Yes, thats great idea

@harshadgohil408 3 ай бұрын

Yes thats how it works

@GodwinStefanSalvatoreAddo Ай бұрын

This introduces a bias.

@AnotherYoutuber-w9z Ай бұрын

22:51 I am seeing this video while tracking delivery person on Zomato .. they track every 10 seconds .. I M noticing so many things .. interesting video

@sudosai 4 ай бұрын

why do we want to shard based on city when all the data can easily fit in memory of a redis server? we can have 2-3 replicas of the primary redis server for availability & serving read requests model = rider id (uuid which takes 16 bytes), status (1 byte for online/offline), location (52 bits or 7 bytes as per redis geohash doc) assuming riders = 10^9 (1 billion), the size estimate becomes 10^9 * (16 + 1 + 7) = 24 GB this can easily fit in a redis server and serve 100k qps / replica which is a lot for this system. --- Liked the pushback on not maintaining a persistent connection. It makes sense and is logical. Clients polling every 2-3 seconds is a simple and effective solution. No need to complicate it and maintain websocket servers or long polling connections which take up memory without adding any business value

@andw2001 9 ай бұрын

Congrats Guys, could get a lot of insight from this talk! Rock on! 😁

@bagirathan8350 7 ай бұрын

don't you think for updating the location its better to have a seperate service where delivery partner sends location updates to which updates the cache instead of delivery matching service since it could have a lot of persistent connections and can be scaled independently, because there may be few orders in a day and some days can have large orders which would make the load on delivery matching service quite high, because anyway we have to update the location of drivers, or am i missing something?

@sumatmallick1697 6 күн бұрын

to the DB. Instead, we can store the location in string format for database purposes and use cache for actual geo-location data. This approach has several benefits: Flexibility: For example, if a rider is making deliveries in Delhi and later moves to Bangalore for personal reasons, the rider can simply share their updated location with the rider manager. The manager can then update the location in the cache. Privacy: Once the rider disconnects, their geo-location data won’t persist, promoting privacy and ensuring compliance with data protection principles. This method keeps the database lightweight and maintains a balance between functionality and privacy. However, I could be wrong, so please feel free to share your thoughts or suggest alternatives.

@RAZREXE 9 ай бұрын

Amazing video as always, thanks Keerti and Gaurav

@chaitanyasravanthi9869 4 ай бұрын

What is this tool you use to draw?

@RamkumarL-o9z 5 ай бұрын

Interesting design and discussion.

@narissakarimahajratalli6779 4 ай бұрын

Can you do a video similar to a food delivery service but with a specific focus on an ordering workflow and restaurant integration?

@sandipan329 7 ай бұрын

@KeertiPurswani, Gaurav, what tool/website do you use to draw the shapes for system design, the one in the video seems really smooth here!!

@unity001 5 ай бұрын

Mirro / Gliffy

@Black_hacker-mj2ro 4 ай бұрын

First Save Data in Redish Cache and distributed cache later on save in your central DB and Delivery boys should be in order of priority queue

@adityashrivastava5018 9 ай бұрын

Which keyboard does gaurav has ?

@BloggerVikash 2 ай бұрын

Along with Api call by person to RiderManager, there should be a limited socket connection as well. Like when the people is on tracking screen or page, the API call will hit, and that will fetch the latest updated location of the rider, but the API will also make a connection with webscoket, and send a message (start_tracking) to get consistent connection update from the Rider. Once he wish to leave that tracking screen or page, send a websocket message(stop_tracking) to disconnect the connection. I think, this will fulfill all the requirement in optimized way. What do you think?