tiennm99/java-design-patterns
1
0
Fork 0
mirror of https://github.com/tiennm99/java-design-patterns.git synced 2026-05-19 01:26:35 +00:00
Code Issues Packages Projects Releases Wiki Activity

fix: Fix minor typos (#2619)

Browse Source 
Signed-off-by: Marcel Ribeiro-Dantas <mribeirodantas@seqera.io>
Co-authored-by: Ilkka Seppälä <iluwatar@users.noreply.github.com>
This commit is contained in:
Marcel Ribeiro-Dantas
2023-10-14 12:59:21 -03:00
committed by GitHub
parent be0d5e5953
commit f79782bea9
30 changed files with 43 additions and 42 deletions
Download Patch File Download Diff File Expand all files Collapse all files
commander/README.md
+1 -1
View File
@@ -18,7 +18,7 @@ This pattern can be used when we need to make commits into 2 (or more) databases
## Explanation
Handling distributed transactions can be tricky, but if we choose to not handle it carefully, there could be unwanted consequences. Say, we have an e-commerce website which has a Payment microservice and a Shipping microservice. If the shipping is available currently but payment service is not up, or vice versa, how would we deal with it after having already received the order from the user?
We need a mechanism in place which can handle these kinds of situations. We have to direct the order to either one of the services (in this example, shipping) and then add the order into the database of the other service (in this example, payment), since two databses cannot be updated atomically. If currently unable to do it, there should be a queue where this request can be queued, and there has to be a mechanism which allows for a failure in the queueing as well. All this needs to be done by constant retries while ensuring idempotence (even if the request is made several times, the change should only be applied once) by a commander class, to reach a state of eventual consistency.
We need a mechanism in place which can handle these kinds of situations. We have to direct the order to either one of the services (in this example, shipping) and then add the order into the database of the other service (in this example, payment), since two databases cannot be updated atomically. If currently unable to do it, there should be a queue where this request can be queued, and there has to be a mechanism which allows for a failure in the queueing as well. All this needs to be done by constant retries while ensuring idempotence (even if the request is made several times, the change should only be applied once) by a commander class, to reach a state of eventual consistency.
## Credits