How we removed a synchronous dependency in an e-commerce system

Imagine an e-commerce application with these services:
 Order Service
 Customer Service
 Shipping Service

Initial Design
When an order is created:
 Order Service publishes an OrderCreated event.
 Shipping Service consumes the event.
 Shipping Service needs the customer's address.
 It makes a REST call to Customer Service.

Shipping Service --> REST --> Customer Service

This works, but creates a dependency:
 Shipping cannot work if Customer Service is slow or unavailable.
 Increased latency due to network calls.
 More service-to-service coupling.

Improved Design: Event-Carried State Transfer

Instead of querying Customer Service every time:
 Customer Service publishes customer updates as events.
 Shipping Service maintains a local copy of customer data.
 When OrderCreated arrives, Shipping Service already has the customer information.

Customer Service --> Kafka --> Shipping Service

Now:
✅ No synchronous REST call
✅ Lower latency
✅ Better resilience
✅ Services are more autonomous
✅ Fully event-driven workflow

🥇 Key Lesson

 Events are not only for notifications.

 They can also be used to transfer state between services.

This pattern is called "Event-Carried State Transfer" and is commonly used in large-scale microservice architectures to reduce service coupling and improve reliability.

Have you used local data replication instead of service-to-service REST calls in your microservices?