My container diagram had three boxes. The actual pipeline had seven hops.

The initial container diagram for the EPCIS batch upload flow in ALSC included three boxes: the Upload API, Processing Service, and Notification Service. However, the actual pipeline was more complex, involving seven separate hops. The process started with a user uploading an EPCIS batch file via a browser request, which was then processed by a Node.js Function that wrote the file to blob storage and sent a message to Service Bus.

A .NET Function picked up the message, performed its tasks, and handed it off to a Hangfire background job, which processed the data further and sent another message back to Service Bus. This final message kicked off another round of processing before completing the cycle. The discrepancy between the three-box diagram and the actual seven-hop pipeline highlights an oversight in the initial design.

The container diagram's focus on deployable units and their structural relationships doesn't capture the runtime flow in detail, particularly in async, queue-heavy architectures. This gap becomes evident during incidents, where tracing the exact path of a failed batch upload across multiple services becomes challenging. The real issue lies in the lack of a dynamic view that shows end-to-end flow diagrams, which would have pinpointed the problematic hop more efficiently.

Implementing distributed tracing with OpenTelemetry and ensuring correlation IDs are explicitly propagated across all service hops resolved the issue, allowing for faster incident resolution. The key takeaway is that a C4 container diagram alone isn't sufficient for async pipelines; it should be complemented with flow diagrams showing real end-to-end scenarios, including hidden hops that don't inherently carry context.