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.
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
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?
