DanielFroehlich
commented
5 years ago Generally, I would try to avoid to implement that low level stuff our self, but delegate to something like mongo, Kafka or so. Also, I would like to avoid the need for that as much as possible. If we have an async event style communication with idempotency of event processing (which is must have for event driven architectures), most of the writing events should be handled correctly.
For example, we wouldnt need a "playlist-controler" at all if the spotify-backend creates a "music stopped" event, where the playlist-component subscribes to.
Heads Up - leaving now the "general event driven architecture disussion field" and hoping into OPenDJ Details:
the tricky part is the spotify-backend with multiple instances, executing calls to spotify. maybe we could delegate the whole problem to spotify . multiple "start playing" calls to spotify in parallel are a "last save wins" strategy which might be fine. Or bad because of interruptions of the music, or API rate limits.
If really really not avoidable, I would think about events like "I am the leader" firing in 100ms intervals. if an instance receives these events, it remains passive. If it is missing these events for more then 250ms sec, it starts firing events and considers itself to be a leader. We dont need 100% consistency here, if in case of a container loss exactly during the transition to a next song there is a small hickup (e.g. the song starting twice), that is acceptable.
This is usually done via some data store, i.e. there's concepts to perform leader election using MongoDB, Zookeeper or etcd. Each choice introduces new technical dependencies, maybe there's a concept for leader election using messaging?