More about requests IDs

Previously we have mentioned about requests IDs to avoid mutating the backend state twice due to a network problem for example. Article link here https://blog.guzman.dev/the-problem-about-api-retry-requests/. But there is more about it.

Have you ever wonder how observability is done in big systems? Like imagine your system is composed of several microservices. Maybe you have a marketplace or online shop. A common architecture would be to have products in one microservice, cart is in another, payment in another and shipping in another. You get the idea, right?

Observability in one system is kind of easy. But when the system expands, it should be looked from above and beyond. You shouldn't look microservices in isolation, they make a tiny work of the whole picture. The same applies for observability, it should be done in isolation. It's kind of unit tests and end to end tests.

What's the keystone in observability in these cases? Well, the answer are tracking IDs. These guys are generated in the very first microservice of the full chain, and are transmitted between the microservices. This is how you track down an operation that goes across different elements in a system, from the very beginning to the end.

These tracking IDs are normally generated and handled in the middleware of you backend application. Once the ID is received, your backend can then inform your observability system, e.g. Jaeger so you can spot the culprit of performance issues and other information.

This is what tracing in microsystem services are in a nutshell.