In a microservices architecture, which communication pattern is typically asynchronous and decoupled?
Asynchronous and decoupled.
Why this answer
Event-driven architecture (D) is the correct answer because it is inherently asynchronous and decoupled: services communicate by publishing events to a message broker (e.g., Kafka, RabbitMQ) without needing to know about the consumers. This pattern allows the producer to emit an event and continue processing immediately, while consumers react to events at their own pace, achieving loose coupling and high scalability.
Exam trap
Cisco often tests the misconception that any HTTP-based communication (like REST) is inherently asynchronous, but REST over HTTP is synchronous by default unless combined with additional patterns like webhooks or message queues.
How to eliminate wrong answers
Option A is wrong because REST over HTTP is typically synchronous and tightly coupled: the client sends a request and waits for a response, creating a direct dependency between services. Option B is wrong because SOAP is a synchronous, tightly coupled protocol that relies on XML messaging over HTTP or other transports, often with strict contract definitions (WSDL) that create strong coupling. Option C is wrong because gRPC, while efficient with HTTP/2 and protobufs, is primarily designed for synchronous request-response communication (though it supports streaming, the default pattern is still coupled and blocking).