The author didn't discuss queues once. I work at a company that uses microservices and queues. Right now we use Rabbit, which is terrible for some reasons I won't get into, but the one good thing about it is that each message has to be acked. You take a message, you process it and then you make that you've processed it.
Things don't get lost. You can requeue messages that end up being dead-lettered due to bugs. You can scale the number of services that read from that queue. You can have services up independently if they just read and write from a system that says, "here's a chunk of data to process."
You can loose data with Rabbit, and if you're starting from the ground up you might want to look at something like Kafka instead. If you don't care about message loss and just need throughput (like if you're doing real time logs or sensor data), something like zeromq might be more appropriate.
The idea behind microservices is that you gain stability at the expense of some redundancy.
Things don't get lost. You can requeue messages that end up being dead-lettered due to bugs. You can scale the number of services that read from that queue. You can have services up independently if they just read and write from a system that says, "here's a chunk of data to process."
You can loose data with Rabbit, and if you're starting from the ground up you might want to look at something like Kafka instead. If you don't care about message loss and just need throughput (like if you're doing real time logs or sensor data), something like zeromq might be more appropriate.
The idea behind microservices is that you gain stability at the expense of some redundancy.