The snowflake id from twitter is a popular solution for the generation of the distributed ids. It is easy to understand and to implement. There are many implementations in different languages that can be found on the internet. It doesn’t rely on any special infrastructure so is easy to scale.
I created a short demo to implement a snowflake id service with Azure Functions. The code is quite simple. For testing, I deployed the code to 2 different regions behind a Front Door and have 2 instances for the function app of each region. It scales quite well. The id generated is always unique and monotonic.
In the code, I used a table storage to maintain the worker id for each host of the function app. The host id of the function app can be retrieved with the environment variable, WEBSITE_INSTANCE_ID. When the function app is called, the code queries the table to get the worker id for the host. If the worker id doesn’t exist in the table, it creates one. In this way, the scaling of the function app can be handled.
In the first version of the code, I used a static class for the function and put the above table query logic in it. It means that there is at least 1 table query for every function call. But the worker id should not change for a host once it is retrieved. It should only be queried once when the host starts. So in the current version, I leveraged the dependency injection of Azure Functions to make the worker as a singleton service. In this way, it is only initialized once for a host and reused for all function calls to that host.
There are two small issues with DI though. It seems hard to debug the DI code in the startup locally. The breakpoint seems never to be hit, and the logger, as it is mentioned in the document, is not ready to be used in the startup. Not sure how to troubleshoot it effectively. On the other hand, DI is only available for .NET Core. There seems no equivalent for other languages as of now.
The code is just for demo purpose. Use it at your own risk.