Communicating to databases is costly in terms of performance and resources. We should not do it unless it is really essential. So we use an in-memory

Problems of Event Sourcing Pattern

submited by

Style Pass

2021-05-31 13:30:11

Communicating to databases is costly in terms of performance and resources. We should not do it unless it is really essential. So we use an in-memory cache to store the most accessed data. But, it is not as easy as it sounds. We can not rely on cached data all the time. We realized that and built an event (our event framework is built by leveraging goroutine) that syncs all the database changes to the cache-store based on the event published.

Basically, published events are consumed within the local instances and an ideal solution until there is a single instance. The problem arose, we decided to go for multi-instances of our backend server. Since only local instances can consume an event published in the event framework, there was no way to communicate with other instances.

Amazon Simple Queue Service (SQS) is a fully managed message queuing service that enables you to decouple and scale microservices, distributed systems, and serverless applications. Simple Notification Service (SNS) is a fully managed messaging service for both application-to-application and application-to-person communication.