Exercise 1: Drawing a Trace Tree for a Gateway → Auth → Search Request — Possible Solution
====================================================================

Trace ID: xyz-789

api-gateway (root span)
  auth-service
  search-service
    cache-lookup
    db-query

Explanation:

api-gateway is the root span -- the first span created, with no
parent, exactly matching the chapter's own gateway example. Both
auth-service and search-service are direct children of api-gateway,
since the gateway is what calls each of them in turn -- they sit at
the same tree depth as siblings, not nested inside one another,
because the exercise specifies search-service is only called AFTER
auth succeeds (a sequential relationship in time), not that
search-service is somehow a child operation of auth-service itself.
Within search-service, cache-lookup and db-query are its own
children, one level deeper, representing operations search-service
performs internally as part of handling its own piece of the request
-- following the same parent-child nesting the chapter's own
inventory-service → db-query example established, where a service
that itself performs sub-operations shows those as its own child
spans.

WHY THIS WORKS AS AN ANSWER
------------------------------
This builds a tree correctly reflecting the described call
sequence -- auth-service and search-service as siblings under the
gateway root, with search-service's own two sub-operations nested
one level deeper as its children -- rather than flattening every
span to the same depth or misreading "called after" as "nested inside."