Timeline for Synchronization of data across microservices
Current License: CC BY-SA 4.0
16 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 29, 2019 at 15:22 | history | edited | Nachiappan Kumarappan | CC BY-SA 4.0 |
added 25 characters in body
|
| May 25, 2019 at 9:09 | review | Suggested edits | |||
| May 25, 2019 at 14:11 | |||||
| May 24, 2019 at 17:56 | answer | added | Chaplin Marchais | timeline score: 4 | |
| May 3, 2019 at 3:56 | comment | added | Nachiappan Kumarappan | @Laiv, Thank you for the hint. After my research, I am also brought to the same place, the same questions. I'll check this further | |
| Apr 23, 2019 at 6:01 | history | tweeted | twitter.com/StackSoftEng/status/1120568265313538048 | ||
| Apr 20, 2019 at 6:11 | comment | added | Laiv | Does RabbitMQ has HA (high availbility) set up? Additionally, in case of failure, you can Queue messages locally until RMQ is up, then you flush the messages into It. | |
| Apr 20, 2019 at 2:42 | comment | added | Nachiappan Kumarappan | Hey @Laiv, I really like your idea of "the less changes to keep in sync the better". We have a reactive mechanism to sync data. Ideally the data is synced within seconds the data is changed. This is by messages that are sent via RabbitMQ. The mechanism is however now fool proof. This mechanism could fail due to sender not being able to reach RabbitMQ, Due to a RabbitMQ going down, the receiver crashing. (It could event be that the service is newly introduced and it needs to get some data from other services) | |
| Apr 19, 2019 at 18:07 | history | edited | Mike Partridge | CC BY-SA 4.0 |
grammar, formatting
|
| Apr 19, 2019 at 12:53 | answer | added | Horia Coman | timeline score: 0 | |
| Apr 19, 2019 at 11:03 | comment | added | Laiv | Having a dedicated process for sync is as I would do it too, however the daily scheduling concerns me. When It comes to synch datasources, the less changes to keep in synch the better. Daily synchs are likely to perform many operations. Have you considered making the synch reactive, so that you can perform the synch based on a operations log length instead of a fixed time rate? | |
| Apr 18, 2019 at 12:45 | comment | added | Nachiappan Kumarappan | @MilanVelebit, I have edited the question. unnecessary complexity is not for the case 4. It's for Case 2 & 3 where RabbitMq is used. RabbitMQ supports broadcast. While broadcast, what if a message is not delivered to one of the recipient. Should be replay the message? If we replay then some recipients get that message twice. So as per our design. Sending messages is to communicate data, and in this medium of communication there is a probability of failure. And we acknowledge this probability of failure | |
| Apr 18, 2019 at 12:28 | history | edited | Nachiappan Kumarappan | CC BY-SA 4.0 |
added 28 characters in body
|
| Apr 18, 2019 at 10:25 | review | Close votes | |||
| Apr 23, 2019 at 3:05 | |||||
| Apr 18, 2019 at 9:34 | comment | added | Milan Velebit | Could you clarify Case 4 through more detail? And what do you mean by this in "this brings unnecessary complexity"? | |
| Apr 18, 2019 at 5:50 | review | First posts | |||
| Apr 19, 2019 at 1:32 | |||||
| Apr 18, 2019 at 5:46 | history | asked | Nachiappan Kumarappan | CC BY-SA 4.0 |