When building microservices, one question comes up quickly:<\/p>\n
How should one microservice communicate with another?<\/strong><\/p>\n Should it call a REST API and wait for a response, or publish an event and let other services react asynchronously?<\/p>\n There is no universal answer. Both approaches solve different problems.<\/p>\n As a developer, I prefer starting with the business requirement<\/strong> rather than the technology.<\/p>\n This article covers where REST and event-driven communication fit, their trade-offs, practical Java examples, and how to choose between them.<\/p>\n REST is one of the most common communication styles in Java microservices. One service exposes an HTTP API and another service calls it.<\/p>\n A simple Spring Boot endpoint:<\/p>\n REST works well when the caller needs an immediate response<\/strong>.<\/p>\n Typical examples include:<\/p>\n For example:<\/p>\n REST itself does not inherently create temporal coupling. The key factor is synchronous communication<\/strong>, where the caller waits for the downstream service to respond.<\/p>\n For example:<\/p>\n If communication between these services is synchronous, a slow or unavailable downstream service can affect the upstream request.<\/p>\n We then need to handle:<\/p>\n This creates temporal coupling<\/strong> because the downstream service needs to be available and responsive at the time the request is made.<\/p>\n REST works well for synchronous request\/response interactions, but long chains of synchronous dependencies can increase the impact of failures and latency across the system.<\/p>\n Instead of calling another service directly, a service publishes an event representing something that has happened.<\/p>\n For example:<\/p>\n The Order Service doesn’t need to know which services consume the event.<\/p>\n It simply publishes:<\/p>\n Each consumer can process it independently.<\/p>\n It is important to distinguish between an event<\/strong> and Kafka<\/strong>.<\/p>\n An event is a message representing a business fact, such as:<\/p>\n Kafka is a distributed event streaming platform that can be used to transport, store, and distribute these messages.<\/p>\n In other words:<\/p>\n Kafka is one technology that can be used to implement event-driven communication. Event-driven architecture is the broader architectural approach.<\/p>\n With Spring Kafka, a producer can publish an event:<\/p>\n A consumer can listen for it:<\/p>\n This approach works particularly well when multiple services need to react to the same business event<\/strong>.<\/p>\n A simple mental model is:<\/p>\n Events are a good fit when multiple independent services need to react to the same action.<\/p>\n For example:<\/p>\n Benefits include:<\/p>\n So I wouldn’t introduce Kafka simply because it sounds more scalable.<\/p>\n Use it when it solves a real business or architectural problem.<\/strong><\/p>\n A consumer may receive the same event more than once.<\/p>\n For example:<\/p>\n The same event may be redelivered because of retries, consumer failures, acknowledgements, or other delivery scenarios.<\/p>\n If processing the event twice causes problems, the consumer should be idempotent<\/strong>.<\/p>\n A simple approach such as checking whether an event was already processed can have a race condition:<\/p>\n For example, two delivery attempts could both execute A more robust approach is to use an atomic deduplication mechanism<\/strong>, typically backed by a database unique constraint.<\/p>\n For example:<\/p>\n The database can enforce:<\/p>\n The consumer can then attempt to insert the event ID atomically. If the event ID already exists, the duplicate can be safely ignored.<\/p>\n The exact implementation depends on the database and processing model, but the important principle is:<\/p>\n Design consumers assuming duplicate delivery is possible.<\/strong><\/p>\n Consumers should not rely on exactly-once processing at the application level.<\/p>\n A common problem occurs when updating a database and publishing an event:<\/p>\n What happens if the database succeeds but Kafka fails?<\/p>\n Now the order exists, but other services never received One common solution is the Transactional Outbox Pattern<\/strong>:<\/p>\n The business record and event are stored together in the same database transaction, and a publisher later sends the event to Kafka.<\/p>\n Event-driven systems often introduce eventual consistency.<\/p>\n For example:<\/p>\n Different services may temporarily have different views of the state.<\/p>\n This is acceptable for many use cases, such as analytics and notifications.<\/p>\n However, if the business requires an immediate result, such as:<\/p>\n synchronous communication may be a better choice.<\/p>\n In real-world microservices, I rarely recommend using only REST or only events.<\/p>\n A hybrid architecture is often the most practical:<\/p>\n Use REST for interactions requiring an immediate response and events for asynchronous business reactions.<\/p>\n When designing a service-to-service interaction, ask:<\/p>\n 1. Does the caller need an immediate response?<\/strong><\/p>\n Yes \u2192 REST is a strong candidate.<\/p>\n 2. Is this a business event?<\/strong><\/p>\n If it naturally sounds like “Something happened”<\/em>, consider an event.<\/p>\n Examples:<\/p>\n 3. Are multiple services interested?<\/strong><\/p>\n If several services need to react independently, events become more attractive.<\/p>\n 4. Can the business tolerate eventual consistency?<\/strong><\/p>\n If yes, asynchronous processing may be appropriate.<\/p>\n 5. Can the consumer safely handle redelivery?<\/strong><\/p>\n If you choose event-driven communication, consider idempotency, retries, acknowledgements, and failure recovery as part of the design.<\/p>\n 6. Is the additional complexity justified?<\/strong><\/p>\n For a simple request such as retrieving customer details, REST is often all you need.<\/p>\n Using REST Everywhere<\/strong><\/p>\n Long synchronous chains can create strong dependencies:<\/p>\n If communication between these services is synchronous, one slow or unavailable service can affect the entire request chain.<\/p>\n Using Kafka Everywhere<\/strong><\/p>\n Not every operation needs to become an event. A simple query can often remain a straightforward REST call.<\/p>\n Confusing Commands and Events<\/strong><\/p>\n A command is an instruction asking a system to perform an action.<\/p>\n An event is a fact stating that something has already happened.<\/p>\n For example:<\/p>\n REST and event-driven communication aren’t competing technologies. They are tools for different requirements.<\/p>\n Use REST when you need an answer.<\/strong><\/p>\n Use events when something happened and other services need to react.<\/strong><\/p>\n An event is a business fact<\/strong>, while technologies such as Kafka provide mechanisms to transport and retain those events.<\/p>\n For most enterprise microservices, the best architecture is often a combination of both:<\/p>\n Start with the business requirement, then consider consistency, failure handling, delivery semantics, scalability, and operational complexity before choosing the communication style.<\/p>\n The goal isn’t to use the most advanced technology. It’s to use the right communication model for the problem<\/strong>.<\/p>\n","protected":false},"excerpt":{"rendered":" Introduction When building microservices, one question comes up quickly: How should one microservice communicate with another? Should it call a REST API and wait for a response, or publish an event and let other services react asynchronously? There is no universal answer. Both approaches solve different problems. As a developer, I prefer starting with the […]<\/p>\n","protected":false},"author":2263,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"iawp_total_views":2,"footnotes":""},"categories":[446],"tags":[4844,3979,2072],"class_list":["post-82910","post","type-post","status-publish","format-standard","hentry","category-java","tag-java","tag-microservices","tag-springboot"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n
REST-Based Communication<\/h3>\n
Order Service | | POST \/payments Payment Service | | PaymentResponse Order Service<\/pre>\n
@PostMapping\r\n public PaymentResponse makePayment(@RequestBody PaymentRequest request) { \r\nreturn paymentService.process(request); \r\n}<\/code><\/pre>\n\n
GET \/customers\/123\r\nGET \/orders\/1001\r\nGET \/products\/500<\/pre>\n
The Problem with Too Much Synchronous Communication<\/h3>\n
Order Service | Payment Service | Fraud Service | Notification Service<\/pre>\n
\n
Event-Driven Communication<\/h3>\n
Order Service | | OrderCreated --> Event Broker \r\n\r\nInventory Service | Notification Service | Analytics Service<\/pre>\n
OrderCreated<\/pre>\n
Event vs Kafka<\/h3>\n
OrderCreated PaymentCompleted ShipmentDelivered<\/pre>\n
Business Event | Event Transport \/ Broker | Consumers<\/pre>\n
Java Example Using Kafka<\/h3>\n
OrderCreatedEvent event = new OrderCreatedEvent(order.getId(), order.getCustomerId(), order.getTotalAmount());\r\nkafkaTemplate.send(\"order-created\", event);<\/code><\/pre>\n@KafkaListener(topics = \"order-created\")\r\npublic void handleOrderCreated(OrderCreatedEvent event) {\r\ninventoryService.reserve(event.getOrderId()); \r\n}<\/code><\/pre>\nREST vs Events: The Core Difference<\/h3>\n
\n\n
\n <\/th>\n<\/tr>\n<\/thead>\n \n REST<\/th>\n Event<\/th>\n<\/tr>\n \n “Give me the customer details.”<\/td>\n “A customer was registered.”<\/td>\n<\/tr>\n \n “Process this payment.”<\/td>\n “The payment was completed.”<\/td>\n<\/tr>\n \n \n“What is the order status?”<\/td>\n “The order was shipped.”<\/td>\n<\/tr>\n \n <\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n REST<\/b> \r\n\"Give me something.\"\r\n\"Do this for me.\"\r\n\"What's the current state?\" \r\n\r\nEvents<\/b> \r\n\"Something happened.\" \r\n\"Here is a business fact.\" \r\n\"React if you care.\"<\/pre>\n
Where Events Work Well<\/h3>\n
OrderCreated | ----> Inventory ----> Notification ----> Analytics ----> Loyalty<\/pre>\n
\n
Event-driven systems introduce their own challenges:<\/h3>\n
\n
Handling Duplicate Events<\/h3>\n
PaymentCompleted(orderId=1001) \r\nPaymentCompleted(orderId=1001)<\/pre>\n
if (processedEventRepository.exists(event.getEventId())) { \r\nreturn; \r\n} \r\norderService.markPaymentCompleted(event.getOrderId());\r\nprocessedEventRepository.save(new ProcessedEvent(event.getEventId()));<\/code><\/pre>\nexists()<\/code> before either one saves the record.<\/p>\nProcessed Events event_id ---------------- evt-123 evt-456<\/pre>\n
UNIQUE(event_id)<\/pre>\n
The Dual-Write Problem<\/h3>\n
orderRepository.save(order); \r\nkafkaTemplate.send(\"order-created\", event);<\/code><\/pre>\nDatabase -> SUCCESS Kafka -> FAILURE<\/pre>\n
OrderCreated<\/code>.<\/p>\nApplication | Database Transaction | ----> Order | ----> Outbox Event | Outbox Publisher | Kafka<\/pre>\n
Eventual Consistency<\/h3>\n
OrderCreated | PaymentCompleted | InventoryReserved | OrderConfirmed<\/pre>\n
Payment Approved \/ Payment Declined<\/pre>\n
The Hybrid Approach<\/h3>\n
Client | Order Service | ---- REST ----> Payment Service | ---- Event ---> Kafka | ----> Inventory ----> Notification ----> Analytics<\/pre>\n
A Practical Decision Framework<\/h3>\n
\n
Common Mistakes<\/h3>\n
A ---> B ---> C ---> D ---> E<\/pre>\n
CreateOrder -> Command OrderCreated -> Event<\/pre>\n
CreateOrder \"Please create this order.\"\r\nOrderCreated \"The order has been created.\"<\/pre>\n
Quick Comparison<\/h3>\n
\n\n
\n \nConsideration<\/th>\n REST<\/th>\n Event-Driven<\/th>\n<\/tr>\n<\/thead>\n \n Communication<\/td>\n Request\/Response<\/td>\n Publish\/Subscribe<\/td>\n<\/tr>\n \n Immediate response<\/td>\n Yes<\/td>\n Usually no<\/td>\n<\/tr>\n \n Queries<\/td>\n Excellent<\/td>\n Usually not ideal<\/td>\n<\/tr>\n \n Multiple consumers<\/td>\n More coupled<\/td>\n Excellent<\/td>\n<\/tr>\n \n Event replay<\/td>\n Not natural<\/td>\n Often supported<\/td>\n<\/tr>\n \n Complexity<\/td>\n Generally lower<\/td>\n Generally higher<\/td>\n<\/tr>\n \n Eventual consistency<\/td>\n Not required<\/td>\n Common<\/td>\n<\/tr>\n \n Duplicate handling<\/td>\n Usually simpler<\/td>\n Important consideration<\/td>\n<\/tr>\n \n Temporal dependency<\/td>\n Present with synchronous calls<\/td>\n Reduced for asynchronous processing<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n Conclusion<\/h2>\n
REST + Events<\/pre>\n