Best way to generate sequential ids

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.

I saw something like ksuid before, the problem is that we need the ids to be inside a particular range, so yeah an increasing counter. For example:

For product A we have the range 202043200000000 to 202043210000000, so the generated numbers would be:

• 202043200000000
• 202043200000001
• 202043200000002
  …

For product B we could have a range of 13200500 to 20500000 so

• 13200500
• 13200501
• 13200502

I would probably have a look at erlang counters if I had to do the same task.

ty for the link, i’ll take a look

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.

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.

The counters should be durable and consistent.

Having gaps is permissible but not ideal

Collisions are a big problem

Overflowing a range should not be an issue (range >>> sale volume)

My first thought was using something like Postgres sequences, but then I thought that having it on application could be a good fit and also help bring some devs in the team into the elixir world

Business constraints, in short we sell insurance policies, we have ranges of reserved policy numbers for different products from different companies, so we are limited to those IDs for public facing documents

@emoragaf I just had similar requirements pop up in my project and I’m wondering if you chose an application-oriented solution?

I currently cluster my Elixir project using libcluster+swarm so I think I can pull this off in pure Elixir/Erlang using globally-named processes. But I’m not looking to reinvent the wheel

edit: fixed a typo

If you use a database like postgreSQL, you can use an auto-incremented sequence.
The problem of using a OTP process is you will still need to serialize it in storage or you will start from 1 again once the cluster reboot. With serialization come with all the ACID problems, so you will be looking precisely at reinventing the wheel.

This will not provide the properties that the OP wants. auto-incrementing sequences do not guarantee sequential ids in records. Sequences are non transactional, so if you open a transaction, insert a record (which increments the sequence), and then rollback the transaction, the sequence is still incremented.