| Th concept of microservices has actually been around for a long time, just under a different guise - see Erlang and it's implementation of concept of the actor model and immutable state. Or the original unix neckbeards' conception of chainable console commands (sed, awk, grep etc.) - small highly specialised commands that do one thing exceptionally well with standardised input and output. Microservice communication will usually work through a message broker such as RabbitMQ or IronMQ - these allow for lightweight routing of messages through subscribed queues, each microservice will listen to an exchange (which has it's own routing rules) which will either round-robin or broadcast to the queues that are attached to it. In a nutshell, a microservice would set up it's input queues (lashed to exchanges) and it's output queues (pushing to exchanges) and react to incoming messages. Messages are pushed to specific exchanges by the microservices creating them, they don't care where they go or what happens once they leave, because once they are in the pipe, they are the next service's problem. You'd want to avoid SPOF such as a Redis instance being polled (the broker deals with that) though you may use it to keep some state information for your various microservices (in case they need to be restarted for example), though ideally, everything should be stateless. The big problem with microservice architecture is that you potentially receive messages out-of-order, or that events happen across your messaging network in different and unexpected orders, so you need to develop defensively against many different situations if you final output requires a combination of states. There's actually a whole pattern-based approach to this which is quite well documented in a book called Enterprise Integration Patterns - though it mainly deals with the idea of the Enterprise Service Bus, the patterns should hold true for a microservice architecture. |