GoKawiilEvery time I happen to use the trace tab in SigNoz (an observability platform), I’m met with the same question, and I put it in the “I’ll deal with this later” folder in my brain.
Until today, when I decided to address the 128-bit elephant in the room.
So, like a normal human these days, I typed into Claude, “Hey, can you explain why a trace-id is 128 bits long??”
And the answer was, surprisingly, a long one.
The answer touches probability theory, distributed systems constraints and fifteen years of industry migration. Let’s actually dig in.
What is a trace ID for, anyway?
When a request enters your system, say, a user clicks checkout, it might bounce through 20 different services, from your API gateway to auth to cart to inventory, etc. Each service does some work and may call other services. To reconstruct what happened when something goes wrong, you need a way to say “all these log entries and spans belong to the same original request.”
That’s the job of a trace ID. It’s generated once, at the entry point, and propagated through every downstream call via HTTP headers like traceparent (or other means of propagation).
So the trace ID has one job, uniquely identify one request’s journey through the system.
Back in our school days, to uniquely identify the students of a class, we had a system in-place which was incremental roll numbers. Why can’t we adopt something similar here, perhaps a counter system?
... continue reading