Request Id¶
Currently we have a single algorithm for generating unique request identifiers, in future we may add other ones if they are required.
99 percent of the time you should treat request_ids as opaque strings, so this documentation is just for your info.
Generation¶
Request id as generated by swindon is 32bytes of url-safe base64 chars
(alphanumeric characters + - and _, no padding as we fit base64
exactly).
Request id is generated from 24 bytes of data consisting of three parts:
- Current timestamp in milliseconds, wrapped at 6 bytes (will wrap in 8k years)
- 12 bytes of random data, which are thread id which accepted thread. These bytes are not synchronized between threads and workers, but it’s assumed that 96 bits of random data is enough to have clashes improbable.
- A per-thread sequence number of request id which wraps at 6 bytes
As you can see you can guess the timestamp from the request id, and request id’s are also k-ordered, i.e. you can sort them alphanumerically and get estimation of sequence of running requests.
Request Id Propagation¶
Sometimes you may want to get request id from another system, this is on our to do list.
Q & A¶
Why request-id is not an uuid4?
There are few reasons:
- Because usually uuid4 is fetched from good random generator source, but we will quickly drain system’s random generator if we use it for every request id. Using PRNG for the task is possible, but that approach doesn’t look like superior to what we have now.
- It’s good to have k-ordered request ids and to know timestamp when request id was generated. Thread id and number may provide additional aid in debugging few kinds of issues (like server crashes and recovery)
- Also our request-ids are shorter, while providing additional info
Downsides:
- Request id provides some info that may be useful for attacker to do some harm. So you should not expose request ids to users.
