In my company we had the exact problem you have and we solved it using Postgres advisory locks:
PostgreSQL: Documentation: 9.4: Explicit Locking Point 13.3.5

So you don’t deal with the concurrency on your elixir application, but on the database level.

So let’s say you want to have a sequential number for product “A”, and 2 concurrent requests come

Request 1 and 2 concurrently:

• 1. Comes in
• 2. Comes in
• 1. Sets advisory lock with id :erlang.crc32("A")
• 2. Sets advisory lock with id :erlang.crc32("A")
• 2. Lock is being used, I’ll wait until it is free
• 1. Query count “A” => returns 2
• 1. Inserts new record with 3
• 1. Finishes transaction and releases lock
• 2. Lock is available, I can proceed
• 2. Query count “A” => returns 3
• 2. Inserts new record with 4

I hope I was explicit enough. Using postgres takes away you a lot of headaches. You don’t need to worry about if your new GenServer is a bottle neck, or if you deploy on a cluster how should you manage your processes.

Do the counters / sequences need to be durable across BEAM restarts, or internally consistent across multiple BEAM nodes? Both of those are challenging with any of the ideas above. Some other questions that come to mind:

Do they need to be monotonic across all machines?
Are gaps permissible?
Are collisions disastrous?
Can you overflow a given product’s range?

Most of these point me towards solutions on the persistent storage rather than application code, i.e. a specialized use of Postgres sequences or similar.

I’d also be curious what real-world or business constraints are at play here since the described technical limitations are unusual.

ksuid generate unique, sortable id.

You could (post/)prepend with your product id if You want.

Now your solution with a Genserver per product could work… it depends how much do You sell, but if You sell too much You might have a bottleneck. It will not work that well in a distributed mode.

It depends also if You just want an increasing counter, or uuid style id.