In this recipe, we created a queue-based microservice that used Redis as a lightweight queueing mechanism. We used a Redis container and discovered this container using DNS. It is interesting to note that in this case, neither the service nor the consumer end had direct knowledge of each other. Rather each simply placed messages onto an intermediary queue.
Our eventservice used the concordant module to discover the Redis service as before, supplying the port and service name for discovery. We are also supplying the name of the internal list structure that Redis should use for these messages, in this case the queue is called eventservice.
The eventservice simply records each event into a MongoDB database and provides a simple report function on this database when requested.
The report tool/service we added also uses concordant. In the report/env.js file we set up some environment variables that concordant uses to contact the DNS server. If the NODE_ENV environment variable is set to production we don't set the DNS_HOST and DNS_PORT, which causes concordant to use standard DNS resolution. We utilize this dynamic in the There's more section of the Deploying a full system recipe in Chapter 11, Deploying Systems.
Now that we have constructed a system with several services, a frontend, and an offline reporting tool, let's take a look at the overall architecture:
This corresponds very closely to the idealized system architecture that we reviewed at the start of this chapter. We should also note that the system adheres to some key microservice principals.