Sending messages through AWS ElastiCache

A while ago we published an article to demo how to use AWS ElastiCache as a data store for a throttling mechanism. AWS ElastiCache is the “in cloud” version of Redis framework: an in-memory key-value datastore, distributed across multiple nodes, that offers sub-milliseconds latency.

In this post we are going to present another use case where this framework could be used: asynchronous communication between services using the Pub/Sub pattern. Basically, in this scenario, Redis is the data store between the sender and the receiver. This scenario is widely described on the official website. Our goal being only to see how to do that using the AWS version of this framework.

Comparing to the others solutions provided by AWS for message sending and receiving, this one is very similar to SNS, because once a message is submitted, it is sent only to the connected subscribed clients, but there is no warranty that message is really delivered. On the other hand, SNS ensures the message is delivered at least once. We found a very interesting article that proposes a solution for implementing a reliable delivery mechanism.

Overall, the code we wrote to demo how to send and receive a message through Redis is available here and being so simple, we are not going to detail it.

Assuming you had cloned the repo, you have only to fill the Redis cluster endpoint in resources/config-prod.properties file, then start the service with prod profile. If you run the service in Beanstalk, you can do that by adding an environment variable named JAVA_TOOL_OPTIONS having value -Dspring.profiles.active=prod. We wrote a detailed article about it because this environment variable is also useful if you run Lambda functions written in Java.

To test a message is sent and received, just call the endpoint and check the logs:

curl -k http://<endpoint>.eu-west-1.elasticbeanstalk.com/hello?name=Cirrus
Hello, Cirrus. This is my first REST service! Simple text message from production stage

And then check the logs:

c.c.d.c.CirrusCloudDemoController        : /hello request.
com.cirrustech.demo.service.Publisher    : Publishing Cirrus.
com.cirrustech.demo.service.Subscriber   : Message received: Cirrus

In the end, the same advice: weight well pros and cons, read carefully the documentation and then decide what pubsub solution is the best for your use case. That one is very cheap and very performant, but some messages could be lost. If you are ok with that, the use it, otherwise go for a classic solution like SNS.

Happy cloud computing to all of you!