Divyansh Rawat — Blogs and Writing

Distributed Tracing Foundations & The Jaeger v2 Architecture Shift

Mon, 26 Oct 2026 09:00:00 GMT

Series: The Jaeger Engineering Reference (Article 1 of 10)
Official Repository: jaegertracing/jaeger
Documentation: jaegertracing.io/docs
Key Upstream Sources: cmd/jaeger/, cmd/jaeger/main.go, cmd/jaeger/internal/extension/jaegerquery/

In a classical monolithic architecture, an incoming request is serviced within a single operating system process boundary. When an endpoint encounters high latency or crashes, diagnosing the failure is relatively direct: an engineer inspects thread dumps, local application logs, or a stack trace using thread-local storage identifiers.

In modern cloud-native distributed architectures, a single end-user action (such as clicking "Place Order" or invoking POST /checkout) fans out across dozens of decoupled microservices communicating across heterogeneous network transports (gRPC, HTTP/REST, Kafka, Redis).

text

User            API Gateway            Order Service           Payment / Inventory            Database
                 |                   |                      |                           |                        |
                 +--POST /checkout-->|                      |                           |                        |
                 |   [Root Span: T1-S1]                     |                           |                        |
                 |                   +--gRPC CreateOrder--->|                           |                        |
                 |                   |  (W3C: T1-S1)        | [Child Span: T1-S2]       |                        |
                 |                   |                      +--HTTP /charge (T1-S2)---->|                        |
                 |                   |                      |                           | [Span: T1-S3]          |
                 |                   |                      |<--200 OK------------------+                        |
                 |                   |                      +--gRPC ReserveStock------->|                        |
                 |                   |                      |   (W3C: T1-S2)            | [Span: T1-S4]          |
                 |                   |                      |                           +--SQL UPDATE items----->|
                 |                   |                      |                           |<--OK-------------------+
                 |                   |                      |<--Stock Reserved----------+                        |
                 |                   |<--Order Created------+                           |                        |
                 |<--201 Created-----+                      |                           |                        |

sequenceDiagram autonumber actor User participant Gateway as API Gateway participant OrderSvc as Order Service participant PaymentSvc as Payment Service participant InventorySvc as Inventory Service participant DB as Postgres / Cassandra User->>Gateway: POST /checkout Note over Gateway: Creates Root Span (TraceID: T1, SpanID: S1) Gateway->>OrderSvc: gRPC CreateOrder (Inject W3C traceparent: T1-S1) Note over OrderSvc: Extracts Context, Child Span (TraceID: T1, SpanID: S2, ParentID: S1) par Concurrent Calls OrderSvc->>PaymentSvc: HTTP /charge (traceparent: T1-S2) Note over PaymentSvc: Child Span (TraceID: T1, SpanID: S3, ParentID: S2) PaymentSvc-->>OrderSvc: 200 OK and OrderSvc->>InventorySvc: gRPC ReserveStock (traceparent: T1-S2) Note over InventorySvc: Child Span (TraceID: T1, SpanID: S4, ParentID: S2) InventorySvc->>DB: SQL UPDATE items DB-->>InventorySvc: OK InventorySvc-->>OrderSvc: Stock Reserved end OrderSvc-->>Gateway: Order Created Gateway-->>User: 201 Created

View Diagram Definition

The contribution heatmap on this site draws fewer weeks on a phone

Tue, 18 Aug 2026 09:00:00 GMT

Every GitHub-style contribution heatmap has the same problem on mobile. The grid is 53 columns of 7 cells. At a 12px cell with a 2px gap that is 742 pixels, and the widest phone in common use gives you about 390. Most sites solve it by putting the grid in a horizontal scroller.

That solution is worse than it looks. The most interesting part of a contribution graph is the right-hand edge, because that is this week. Put it in a scroller and the default view shows a year ago, with the part anyone cares about parked off-screen behind a gesture nobody performs.

Ask the container first#

The grid on this page measures its own host before it draws anything:

function weeksThatFit(prefix) {
                    var grid = document.getElementById(prefix + '-grid');
                    var host = grid && grid.parentElement;
                    var w = host ? host.clientWidth : 0;
                    if (!w) return WEEKS_MAX;
                    return Math.max(10, Math.min(WEEKS_MAX, Math.floor(w / cellStep())));
                }

cellStep() returns 14 on desktop and 12 below 560px, matching the cell and gap sizes in the stylesheet. Whatever comes back is how many week-columns get rendered, ending with the current week. On a laptop that is the full 53. On a phone it is closer to 30.

The count under the grid then has to stop lying about the range:

var span = WEEKS >= WEEKS_MAX
                    ? 'in the last year'
                    : 'in the last ' + Math.max(1, Math.round(WEEKS / 4.345)) + ' months';

So a phone reads "412 contributions in the last 7 months" instead of claiming a year it never drew. Fewer weeks, no scrollbar, and the label is still true.

There is one catch. Column count depends on width, so rotating the phone invalidates the layout. A resize listener re-runs weeksThatFit and only re-renders when the number actually changed, which is why the rendered counts are kept in memory rather than refetched.

Shading against yourself, not against a constant#

The other thing worth doing differently is the colour ramp. Fixed thresholds — 1 commit is level one, 10 is level four — make a normal month look empty next to whoever you borrowed the thresholds from.

These cells are bucketed against the quartiles of the person's own non-zero days:

var q = function (p) { return vals[Math.min(vals.length - 1, Math.floor(vals.length * p))]; };
                var t1 = q(0.25), t2 = q(0.5), t3 = q(0.75);

A quiet year still shows contrast, because the scale is relative to that year. It is a graph of your rhythm, not a leaderboard.

Codeforces makes you work for it#

The last piece is unrelated to layout but was the thing that actually kept the card blank. Codeforces rate-limits to roughly one call every two seconds, and it signals a violation by returning HTTP 200 with {"status":"FAILED"} in the body.

A 200 that means failure defeats every fetch().then() you have written. r.ok is true, JSON.parse succeeds, and you render a card from an error.

Two things fix it. Check status rather than the HTTP code, and space the calls out instead of firing them together:

function cfUnwrap(d) {
                    if (!d || d.status !== 'OK' || !d.result) {
                        throw new Error(d && d.comment ? d.comment : 'CF request failed');
                    }
                    return d.result;
                }

The card also has a serverless proxy behind it as a second route, which helps mostly because it comes from a different source IP and caches at the edge.

And when both routes fail, the card does not disappear. It renders an empty grid with a note saying the API could not be reached. A block that silently vanishes reads as a broken layout. A block that says what went wrong reads as a site someone maintains.

You cannot be dumb and lazy at the same time

Tue, 18 Aug 2026 09:00:00 GMT

There is a blunt rule of thumb that holds up everywhere in engineering: you can be unexceptional, or you can be lazy, but you cannot afford to be both.

If you are terrifyingly sharp, you can get away with working four hours a day. You glance at a stack trace, spot the unindexed database scan or the off-by-one race condition in three minutes, write a fifteen-line fix, and move on. Your leverage is high enough that your output looks effortless.

If you aren't that person—and almost nobody is when they start—you still have a completely viable path: you just outwork the gap. You pull down the library's source code instead of guessing what the docs meant. You fire up a debugger and step through twenty stack frames. You write a script that generates ten thousand edge-case payloads until the bug reproduces locally. It takes longer, but you arrive at the exact same truth.

The disaster is when people try to borrow the work habits of the first person while possessing the context of the second.

The guessing game#

You see this most clearly in how people debug.

When someone lacks both deep understanding and the patience to grind, debugging turns into superstition. They change a variable name, wrap a synchronous call in an unnecessary retry loop, sprinkle random null-checks, and rerun the test suite. If it passes once, they push to main and pray nobody touches it again.

Nothing was diagnosed. No invariants were verified. The underlying race condition or memory leak is still there, quietly waiting for traffic to spike.

It happens because genuine diagnosis is tedious:

Reading a 40-page protocol spec when you only care about three fields.
Profiling memory allocations under load instead of blindly bumping the container's RAM limit.
Tracing raw TCP packets when a connection drops silently behind a reverse proxy.

None of that is glamorous work. It is mostly reading, testing hypotheses, and being wrong ten times in a row before finding the one line that actually matters.

The leverage tax#

Productive laziness is real, but it is an earned state.

The engineers who build clean, minimal systems aren't "lazy" in the sense that they skip the hard parts. They are lazy in the sense that they refuse to solve the same problem twice. They spend three days designing a clean abstraction or writing an idempotent pipeline specifically so they never have to wake up for an on-call alert on Saturday.

That kind of simplicity requires enormous upfront cognitive work. Making something simple is much harder than making something complicated.

If you don't have the mental models yet to build that leverage, you can't skip straight to the relaxed afternoon. Your only real option is to put in the hours: read the manuals, write the test harnesses, inspect the logs, and build the intuition from scratch.

One handicap is workable. Both at once is just negligence.