I'm curious about the best ways to manage state changes between different applications. For example, if App A updates a certain state, and then App B needs to respond to that change, what approaches should I consider? Would using Redis be a good option, or should I stick with traditional databases?
5 Answers
Honestly, just go with a database if you want a straightforward approach. Sometimes keeping it simple is best.
It all kinda depends on how your architecture is set up. Using a message queueing system like Apache Kafka between your services could also be beneficial. For example, Service A could send a message to Service B that triggers an event on B.
Using a shared database can work, but it gets tricky if one of the apps only has read access. Redis is definitely a solid choice here. Personally, I’d prefer to put my database behind an API, allowing both apps to interact through that. It just feels safer that way!
If real-time updates are crucial, consider implementing a pub/sub system that sends events for each state change. If real-time isn’t as critical, then you could stick with regular updates through a REST API. Just my two cents, I'm still learning myself!
I’ve had a bit more experience, and I think this approach is right on point! One API can take charge of managing the state of a domain object and publish any changes. This way, other systems can react accordingly.
Ever heard of Convex? It's another option to explore if you're looking into modern solutions for state management!
But what if Redis becomes unavailable or overloaded? It might be a good fallback to have the database in case of such issues. Just remember, we can't always rely on other systems to have the latest info! A focus on eventual consistency is key.