nodejs/nodebestpractices
1
0
Fork 0
mirror of https://github.com/goldbergyoni/nodebestpractices.git synced 2025-11-04 04:13:54 +08:00
Code Issues Packages Projects Releases Wiki Activity

One Paragraph Explainer: Async functions usecase is primary instead of microservice

Browse Source
This commit is contained in:
Yedidya Schwartz
2021-02-03 22:17:58 +02:00
committed by GitHub
parent 2c619f55d8
commit 38c21fefa4
1 changed files with 2 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

3
sections/errorhandling/correlationid.md
View File

@ -2,7 +2,8 @@
### One Paragraph Explainer ### 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.
<br/> <br/>