Concurrency, queue functionality in webservice

Ask the community
1

Hi all. We are trying to create a meeting room booking solution where it should be impossible to book the same meeting room on the same time. We are currently trying to achieve this by isolating this function to a webservice. One solution would be that the webservice would queue up all requests coming in and process one at a time. The combinations of using “No Concurrency” and “Run Async” does not seem to yield the right result. In a SQL server approach, I would solve this by using a stored procedure that only inserts the new booking if there are no bookings in the time slot in the database.
How to best solve this in APPFarm?
Any feedback is appreciated :slight_smile:

Øystein

2

Hi Øystein,

I believe that using “No Concurrency” could lead to issues in your situation.

If I understand correctly, you should be able to receive two requests for different meeting rooms at the same time, right?

Additionally, if “Run Async” is enabled, it means that if a room is unavailable, your customer won’t be notified immediately.

If checking a combination of time, date, and meeting room in your service still causes issues, here’s a potential solution:

  • Introduce a new field called “Reference” in your booking database.
  • Ensure this value is unique to prevent duplicate entries.
    image
    image230×109 2.77 KB
  • The reference can be generated using a combination of unique elements such as date, time, and meeting room ID.

At the end of the process, persist the booking:

  • If the reference doesn’t exist, it will be stored successfully.
  • If it already exists, an error will be triggered, allowing you to notify the customer immediately.

P.S : if booking duration is flexible, you should also think it differently but based on that “reference”

This approach could also be a great opportunity to refresh the customer’s view dynamically.

Hope this helps :smiley:

2 Likes
3

Hi Yassine and thank you for your reply. The “unique” approach could work if there are consistent periods. The bookings may pass into a period, pass out of a period, pass through a period, and reside inside a period. I dont quite see how that would work with this complexity. Could you elaborate more on your idea for the solution given this?

Øystein

4

Hi Øystein,

Indeed, booking duration flexibility adds complexity to the solution.

This may require some compromises on your end if the easy solution is not working.

A couple of key questions:

  1. Is it necessary to keep “Run Async” enabled?
  2. Is there a defined minimum booking time?

On top of my mind, If a minimum booking time exists, one possible approach is to split reservations into fixed intervals (you can visually adapt it for the customer to look like one block )

Not sure if it’s the best option but here it is

Example:

Assumptions:

  • Minimum booking time: 30 minutes

Existing Booking:

  • Room A booked on 14/03/2025 from 09:30 to 10:00

New Booking Request:

  • Room A from 09:00 to 10:30

Proposed Solution:

  • Split the new booking into three 30-minute slots:
    • Booking 1: (Reference : A-14032025-0900) → 09:00 - 09:30
    • Booking 2: (Reference : A-14032025-0930) → 09:30 - 10:00
    • Booking 3: (Reference : A-14032025-1000) → 10:00 - 10:30
  • Since Booking 2 (A-14032025-0930) already exists, a uniqueness constraint will trigger an error.
    image

What you must do:

  • Persist all three bookings together ( not seperatly).
  • If any of them fail due to a uniqueness constraint, Appfarm will reject the entire transaction. (you will not have Booking 1 and 3 in your DB)
  • Catch that error and handle it to normalize it for your customer

Other info :

  • it is a bit complexe to do it like this, and there is probably a better solution for that
  • in order for you to handle it easily, you can imagine having your uniqueness constraint in another table. for exemple
    – a main DB Booking that will have all your basics info
    – a linked DB Booking Slots that will contain all your slot with your constraint

In our exemple it will be

  • One Line in Booking
    – ID 123456
    – Booked By *****
    – Booking Start 14/03/2025 09:00
    – Booking End 14/03/2025 10:30
    – Booked Room A
  • 3 Lines in Booking Slots with uniqueness constraint
    – Reference A-14032025-0900
    – Booking parent 123456
    –
    – Reference A-14032025-0930
    – Booking parent 123456
    –
    – Reference A-14032025-1000
    – Booking parent 123456

Would this approach be feasible for your case? Let me know your thoughts!

1 Like
5

Have you considered building 2 endpoints, where
Endpoint 1 is “no concurrency” for internal DB consistency and then
Endpoint 2 which is not and act as the que and is the “public” booking endpoint

The 2 service can hold parallel incoming booking request with a sleep logic if concurrency error.

The 1 service has logic ensuring consistent database while the 2 act based on response from 1. I assume that this logic will not be overrun with bookings?

1 Like
6

Waaay easier xD

the only problem is that you cannot recieve two bookings request on two different meeting room at the same time.

still very easy to implement and maintain ( i went too far haha )

1 Like
7

Haha your solution is much cooler though :smiley:

I imagine 2 bookings at the same time would resolve quick enough still given it is not 1000+ rooms :slight_smile:

8

Thank you both for the replies. I think both approaches might work, and we will test them :slight_smile:

1 Like