From 38c21fefa430bc3b7860a6317820baf774855950 Mon Sep 17 00:00:00 2001 From: Yedidya Schwartz <36074789+yedidyas@users.noreply.github.com> Date: Wed, 3 Feb 2021 22:17:58 +0200 Subject: [PATCH] One Paragraph Explainer: Async functions usecase is primary instead of microservice --- sections/errorhandling/correlationid.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/sections/errorhandling/correlationid.md b/sections/errorhandling/correlationid.md index fe401a7c..0f3617b0 100644 --- a/sections/errorhandling/correlationid.md +++ b/sections/errorhandling/correlationid.md @@ -2,7 +2,8 @@ ### One Paragraph Explainer -Correlation ID is one of the best problem-solving patterns. It lets you link log records, even if they belong to different services. If your system consumes other services and is itself a producer service, adding a correlaction ID is a must. By this pattern, your transaction logs can become into a story that tells itself by filtering your logs with a specific correlation ID, instead of try linking the cross-services transaction logs to each other by yourself. It can save your day when a process including 20 different microservices throws an exception in one of them, and you have no idea where did the problem start across the flow. +Correlation ID is one of the best problem-solving patterns. It lets you link log records, even if they belong to different async functions, or even different services. If your process includes calls of 20 async functions, adding a correlaction ID to your logs is a must. This may be your only way to tell that a specific entry from the controller layer belongs to the same request as that entry from the DAL layer. +Moreover, if your system consumes other services and is itself a producer service, this practice can help you. By adding a correlation ID, your transaction logs can become into a story that tells itself by filtering your logs with a specific correlation ID, instead of try linking the cross-services transaction logs to each other by yourself. It can save your day when a process including several different microservices throws an exception in one of them, and you have no idea where did the problem start across the flow.