JUST A POC to demo for the team. Don't use the code in production.
When generating event from an API when stuffs are written for change, the event operation might fail because of throttling, network issues etc
- Implement a retry policy that runs things in background
Can work, but that means, we cannot restart instances which are
doing retries.
- Two phase commits
More complex
Bad User Experience?
- Have a concurrent worker listening to events happening in one API instance.
Same problem as 1
- Have a separate service reading from mysql binlog
Not sure how multi server setup is going to work
More moving part, but can be solved if run as a go process
Having solution 2 & 4 will be more available and consistent system. (Throwing in buzz-words??) But 2 is complex in terms of implementation.