Microservices encapsulate business logic in separate applications and allow independent scaling of these services. For example, an HR solution might have several micro-services split up between codebases, operating systems, geographic locations, or service providers. Having microservices, also commonly referred to as Service-Oriented Architecture, allows each service to be managed and developed independently.
In a Ruby on Rails Microservices environment, sharing data and propagating events between services does not come out of the box. However, several tools are readily available to handle these cases, ranging from Ruby background job libraries, like Sidekiq and Delayed Job, to queuing solutions, to enterprise-scale solutions designed for high volume throughput, dynamic scaling and redundancy. Let’s look into a few use cases.
For an environment with one-to-one server communication, asynchronous API calls from one service to another maybe sufficient. For example, when a Ruby on Rails Service A receives a request and needs to update a Ruby on Rails Service B, a background worker can be called by Service A to handle the asynchronous API call to Service B.
For an environment of one-to-many, one worker per recipient per separate service may be reasonable for a small number of services. For example, Service A might make API calls to Service B and Service C using a background job.
In more complex service environments, posting to intermediaries might be more useful. Services such as Amazon SQS (Simple Queue Service) and RabbitMQ allow services to publish and subscribe (producer-consumer) to queues, effectively decoupling your services from each other. For example, service A could publish data to Queue B for Service B, and publish to Queue C to be consumed by Service C. For enterprise-grade messaging services Apache Kafka and Amazon Kinesis are among several solutions.
Which solution works for you will ultimately depend on your resources and your particular situation. Time, costs, throughput and complexity are considerations when choosing how to communicate between microservices.