Exercise 2: Why a Correlation ID Beats Timestamp Correlation — Possible Solution
====================================================================

WHAT log1'S TIMESTAMP-BASED TECHNIQUE RELIES ON
------------------------------
log1's own correlation technique narrows log entries down by
approximate timing - confirming a log entry's timestamp lines up with
when a reported problem happened, then reading nearby entries to
piece together what occurred around that moment.

WHAT A CORRELATION ID PROVIDES INSTEAD
------------------------------
Per this chapter, "well-designed APIs return a request ID or
correlation ID with every response... specifically so a user-facing
error can be matched to the exact server-side log line that explains
it." Rather than narrowing down to "roughly when this happened," a
correlation ID identifies the precise log entry (or entries) generated
by that exact request.

WHY THIS IS A GENUINE UPGRADE
------------------------------
Per this chapter, this replaces "narrowing down logs by 'roughly when
this happened'" with letting you "grep for the exact request, no
ambiguity at all." Timestamp correlation can still leave multiple
candidate log entries in a busy window with many concurrent requests;
a correlation ID removes that ambiguity entirely by identifying the
single request in question directly, regardless of how many other
requests were happening at the same moment.

WHY THIS WORKS AS AN ANSWER
------------------------------
It explains what timestamp correlation actually provides (an
approximate window) versus what a correlation ID provides (an exact
match), and explains specifically why removing the ambiguity of
"roughly when" is a genuine improvement, not just a different way of
doing the same thing.