Hi, first of all thank you for IdGen. It works very well for distributed technical IDs, especially database primary keys and other internal identifiers.
I would like to suggest adding support for positive Int32 IDs, using the same general approach as the current Int64 implementation.
Today IdGen generates Snowflake-like 64-bit IDs, effectively 63 usable bits because the sign bit is not used. For an Int32 variant, the equivalent would be positive signed Int32 IDs with 31 usable bits.
The current IIdGenerator<long> behavior is a great fit for technical IDs, but there are cases where a smaller numeric identifier is useful for business-facing document numbers, for example:
- Invoice numbers
- Purchase order numbers
- Document numbers
- Case/request numbers
- Other short numeric references shown to end users
For these cases, a long Snowflake ID can be larger than necessary and less friendly when displayed, read aloud, printed, or entered manually.
The proposed feature would be an Int32 generator that implements IIdGenerator<int> and is behaviorally compatible with the existing IIdGenerator<long> approach: timestamp, generator-id, and sequence parts; configurable bit allocation; positive generated values; and similar overflow/wraparound behavior where applicable.
This is not intended to provide gapless document numbering. If gapless numbers were required, a sequence/table-backed allocator would usually be a better fit. The goal is compact, distributed, time-aware numeric IDs for document/reference numbers where gaps are acceptable.
Some example Int32 configurations:
| Type |
Timestamp Bits |
Generator ID Bits |
Sequence Bits |
Max Intervals |
Max Generators |
Max Sequence IDs |
Epoch |
Tick Duration |
Wraparound Date |
Wraparound Interval |
| Int32 |
25 |
4 |
2 |
33,554,432 |
16 |
4 |
2026-01-01 |
0.00:01:00.000 |
2089-10-18 |
23301.16:32:00.000 |
| Int32 |
21 |
10 |
0 |
2,097,152 |
1,024 |
1 |
2026-01-01 |
0.00:15:00.000 |
2085-10-23 |
21845.08:00:00.000 |
| Int32 |
21 |
4 |
6 |
2,097,152 |
16 |
64 |
2026-01-01 |
0.00:15:00.000 |
2085-10-23 |
21845.08:00:00.000 |
| Int32 |
19 |
10 |
2 |
524,288 |
1,024 |
4 |
2026-01-01 |
0.01:00:00.000 |
2085-10-23 |
21845.08:00:00.000 |
| Int32 |
19 |
6 |
6 |
524,288 |
64 |
64 |
2026-01-01 |
0.01:00:00.000 |
2085-10-23 |
21845.08:00:00.000 |
| Int32 |
19 |
4 |
8 |
524,288 |
16 |
256 |
2026-01-01 |
0.01:00:00.000 |
2085-10-23 |
21845.08:00:00.000 |
| Int32 |
19 |
0 |
12 |
524,288 |
1 |
4,096 |
2026-01-01 |
0.01:00:00.000 |
2085-10-23 |
21845.08:00:00.000 |
| Int32 |
18 |
10 |
3 |
262,144 |
1,024 |
8 |
2026-01-01 |
0.02:00:00.000 |
2085-10-23 |
21845.08:00:00.000 |
| Int32 |
17 |
10 |
4 |
131,072 |
1,024 |
16 |
2026-01-01 |
0.04:00:00.000 |
2085-10-23 |
21845.08:00:00.000 |
These examples show the kinds of tradeoffs that would be expected with only 31 usable bits: fewer sequence IDs per tick, longer tick durations, fewer generators, or shorter/longer wraparound windows depending on the chosen structure.
Would this kind of IIdGenerator<int> support fit the scope of IdGen?
Hi, first of all thank you for IdGen. It works very well for distributed technical IDs, especially database primary keys and other internal identifiers.
I would like to suggest adding support for positive Int32 IDs, using the same general approach as the current Int64 implementation.
Today IdGen generates Snowflake-like 64-bit IDs, effectively 63 usable bits because the sign bit is not used. For an Int32 variant, the equivalent would be positive signed Int32 IDs with 31 usable bits.
The current
IIdGenerator<long>behavior is a great fit for technical IDs, but there are cases where a smaller numeric identifier is useful for business-facing document numbers, for example:For these cases, a
longSnowflake ID can be larger than necessary and less friendly when displayed, read aloud, printed, or entered manually.The proposed feature would be an Int32 generator that implements
IIdGenerator<int>and is behaviorally compatible with the existingIIdGenerator<long>approach: timestamp, generator-id, and sequence parts; configurable bit allocation; positive generated values; and similar overflow/wraparound behavior where applicable.This is not intended to provide gapless document numbering. If gapless numbers were required, a sequence/table-backed allocator would usually be a better fit. The goal is compact, distributed, time-aware numeric IDs for document/reference numbers where gaps are acceptable.
Some example Int32 configurations:
These examples show the kinds of tradeoffs that would be expected with only 31 usable bits: fewer sequence IDs per tick, longer tick durations, fewer generators, or shorter/longer wraparound windows depending on the chosen structure.
Would this kind of
IIdGenerator<int>support fit the scope of IdGen?