mirror of
https://github.com/goldbergyoni/nodebestpractices.git
synced 2025-11-02 11:11:41 +08:00
One Paragraph Explainer: Async functions usecase is primary instead of microservice
This commit is contained in:
@ -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.
|
||||
|
||||
<br/>
|
||||
|
||||
|
||||
Reference in New Issue
Block a user