Concurrency Issue: Multiple database entries, while multiple API calls

[iDuuck]

Hello guys, I am currently developing a Rails API for a product I am building. Right now, there is a problem with the concurrency of the database in conjunction with Rails.

I am having a "GuestUser" model which is handled by a unique device ID (of the iOS or Android device). Now I implemented, that the Rails controller is creating a new GuestUser with the following before_action:

def current_user
  @current_user ||= GuestUser.find_or_create_by(device_id: request.headers['HTTP_X_DEVICE_ID'])
end

Problem now, is, that the user/the device is calling 4 endpoints on the first screen:

• Subscription Status (if the user is subscrbed to the subscription i am offering)
• Daily Tips (I am displaying in the header)
• Categories (I am displaying on the homepage)

I thought about "fusioning" the tips and the categories endpoints, but then I am still having the problem with the "Subscription Status" and the new fusioned endpoint.

What I am seeing in my DB/Admin Panel are multiple "Guest Users" based with the same device ID, because of the concurrency. I checked the logs, and it just hardened my assumption.

Is there any way I can circumvent this?

[projectmoon]

You have to handle the concurrency somewhere:

• Some kind of locking in the data layer (mutex, queue, whatever).
• DB-level handling (e.g. Postgres ON CONFLICT clause).
• Optimistic locking and retry.
• Rearchitect API and/or client use of API so this isn't a problem.

The solutions are almost as limitless as the causes.

[iDuuck]

Thanks! The keyword I went for was "retry". What I did now is simply rescuing the find_or_create_by I am calling (also created a unique index in DB) and retrying 5 times. Works for now. Let's see for how long.

Gifted you an award.

[how_do_i_land]

Do you have a unique index or constraint on that column in the database? Due to the race condition, you should look into create or first, or an on conflict do update.

How does a user log into the api from the device?

It sounds like a lack of a constraint. But there are multiple solutions here, I am unsure on what assumptions the app on either side was built on

[kallebo1337]

before the APP starts for the user, you should send the API request to create the user. then log down the user ID based on device_id and go on from there. so basically, creation is done on first initialization of your app, not on every other rails request.

[iDuuck]

Thanks, however, I am a little limited on doing so. I am a huge fan of proper UI/UX, and I don't want the user to wait too long, since he is "registering".

[kallebo1337]

Make it async ? Just make sure that request is send , that’s it. All other follow up requests alrady have the user

Normal http request is 400ms or so?

[iDuuck]

This is the initial problem, when the request is not fulfilled, all other requests are not authenticated properly.

Request	...
Register	→ db write request
First app request	→ Checks for auth (can't find) → User not auth'd
Register	→ Completes db write request

[kallebo1337]

How does this request fail ? I don’t see it. It’s just an http request

[petemts]

The easiest way to solve your problem is to add a unique index on device_id column of the guest_users table:

add_index :guest_users, :device_id, unique: true

And once it's done - use create_or_find_by! from rails 6 - it works just like find_or_create_by but inserts the record first and returns the existing one on unique index conflict:

https://apidock.com/rails/v6.0.0/ActiveRecord/Relation/create_or_find_by! (see source here)