In this post, I’ll walk through a sample implementation of the simplest way to maintain an Event Projection: an in-memory lookup table. I’ll use this sample to illustrate when this is a suitable approach to use.
The objective for this demo
In Comparing approaches to maintaining an Event Projection from Kafka topics, I introduced the pattern of Event Projections.
I also introduced the scenario that I’ll be using in these demos. Please see that post for the detail and motivation, but to recap: I will maintain a projection of the data from two Kafka topics (one based on the event key, the other based on an attribute in the event payload).
In both cases, I want to be able to make an HTTP/REST call to retrieve the data that was in the most recent event to match my query.
At a high-level, the goal was to create a single server that will:
- subscribe to my Kafka topics
- maintain an in-memory lookup of the relevant data
- provide an HTTP/REST API for querying the projection
For demo purposes, my “application” will be curl, so I can illustrate being able to query the projection like this.
