How Should I Handle Real-Time Provider Availability in an On-Demand App?

[Robert_184]

I'm working on an on-demand application where customers can request a service and nearby providers can accept the request.

I'm trying to figure out the best way to handle provider availability on the backend. For example, a provider may become available, receive multiple requests, accept one, and then immediately become unavailable to other customers.

What would be a good approach for handling this reliably?

I'm particularly interested in:

Preventing two customers from booking the same provider
Updating provider availability in real time
Choosing between WebSockets and polling
Handling location-based provider searches
Managing concurrent booking requests
Designing the database transactions to avoid race conditions

Would Redis, WebSockets, or database locking be appropriate for this type of system? I'd appreciate advice from anyone who has implemented a similar workflow.

[Salem]

Here you go, contact the other poster with the same question and compare notes.

https://www.daniweb.com/programming/software-development/threads/545347/location-based-handyman-app-with-real-time-job-matching

[trcooke]

You've essentially asked the same question twice, for reasons unknown.

Regardless, I gave a suggestion in your other post

[Annie warner]

I would keep the database as the source of truth and use Redis and WebSockets for performance and real time updates.
Use an atomic transaction or row-level lock to change a provider from available → busy so two customers can not book the same provider. PostGIS is a good choice for finding nearby providers.
WebSockets work well for real time availability while polling is simpler but less efficient. Redis can handle caching temporary locks and location data but should not be the only source of truth for bookings.

[trcooke]

I would keep the database as the source of truth and use Redis and WebSockets for performance and real time updates.
Use an atomic transaction or row-level lock to change a provider from available → busy so two customers can not book the same provider. PostGIS is a good choice for finding nearby providers.
WebSockets work well for real time availability while polling is simpler but less efficient. Redis can handle caching temporary locks and location data but should not be the only source of truth for bookings.

That is quite a lot of complexity. If you made the booking request processing single threaded and handle requests in order of receipt then you eliminate a lot of the complexity you mention here that is required to handle concurrent multi-threaded booking requests.