In an event-driven architecture, microservices don't communicate through REST APIs, but via a message passing framework (RabbitMQ, Kafka, etc.). As you correctly pointed out, microservices react to a message received on a particular topic/channel they listen to.
If the microservice is down, the message accumulates in the message bus and it gets processed either by the same microservice (when it gets back up) or by another one.
If they were to communicate through REST APIs and a microservice is down, you need to retry the request with an exponential backoff policy and take care of many other things. This article explains the difference really well.
A microservice system can be entirely built with REST microservices. It just doesn't follow the event-driven approach, but more like a synchronous (request/response) model. The design of your microservice system should be directly correlated to the requirements of your application.
Usually, a hybrid approach is used: you communicate with some microservices through REST APIs (for example with autentication/autorization microservices), because you need the response from them ASAP. With other ones, you can communicate through events, usually when you have fire-and-forget events, like logging, metrics, maybe storage.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…