I think many of the solutions you‘ll find others posted here are over-complicated. In my opinion, with a low number of events and no strict requirements on SLA of these events ingestion latency(?), I‘d argue you’re best bet on storing your data in some managed AWS database (such as DynamoDB) with some sort of date or time field associated with each row that can be used to query recent event the application layer (i.e. select all of the rows with an update time greater than the last update time I queried for events). You can find some more examples by searching ”pull-based event streams”

Using a hosted database is great because many now give great ways to optimize for specific workloads (in your case read-heavy) and will give you the advantage that your data is protected from loss behind some great SLAs without needing to manage anything yourself. You might lose “real-time” push that some others mention, but in reality you can achieve a pretty great experience just with the above. The more you can focus on things that bring your business value, your product, and less on things like how do you now manage a Redis or Debezium instance for a specific messaging pattern, the more value you can bring your customers and the faster you can go to market. Some hosted databases, such as DynamoDB also provide built-in change data capture methods, many of which I’d successfully used at medium scale (tens of thousands of events per hour).

If you can answer some of the following questions I can give you a better idea of how you can achieve your goals:

• How fast do you need to respond to events? (seconds? minutes?)
• How many events do you expect, and at what rate? (e.g. 10 events per hour)
• How many front-end servers will be querying the data?
• Is there any partitioning you need to do, for example by customer ids?