Event-Driven Architecture vs. Request-Response: When to Choose?EDA

Event-Driven Architecture vs. Request-Response: When to Choose?EDA

Not long ago, most apps used the Request-Response style. A user clicks a button, the app sends a request, waits for a response, and then shows the result. It’s simple but can feel slow and tightly linked?—?especially when many services must talk to each other.

Now, we have Event-Driven Architecture (EDA), where different parts of your app “listen” to events. For example, if a new order is placed, multiple services (billing, shipping, notifications) can react at once without waiting on each other. This can make your app faster, more flexible, and easier to scale.

If you want your system to handle lots of events quickly like a busy e-commerce site during a big sale EDA might be the way to go. But if your app is small or each request needs immediate feedback (like a user login), a Request-Response approach might still work. In many cases, you’ll have a mix of both.

  • Request-Response: The client waits for the server to finish.
  • Event-Driven: Multiple services respond on their own, without blocking each other.

Below is a simplified example showing Request-Response vs. a basic Event-Driven pattern in C#.

1. Request-Response Example

// Typical Controller Method in ASP.NET Core
[HttpGet("GetUserInfo")]
public async Task<IActionResult> GetUserInfo(int userId)
{
    // The client waits for this process
    var userInfo = await _userService.GetUserByIdAsync(userId);
    return Ok(userInfo);
}        

The client calls GetUserInfo and waits until the server returns data.

2. Event-Driven Example (Using RabbitMQ or Any Message?Broker)

public class OrderService
{
    private readonly IMessageBroker _messageBroker;

    public OrderService(IMessageBroker messageBroker)
    {
        _messageBroker = messageBroker;
    }

    public void PlaceOrder(Order order)
    {
        // Save order to database or do basic checks
        // Then publish an event for other services
        _messageBroker.Publish("NewOrderPlaced", order);
    }
}

// In a different service, you subscribe:
public class ShippingService
{
    public ShippingService(IMessageBroker messageBroker)
    {
        messageBroker.Subscribe<Order>("NewOrderPlaced", (order) =>
        {
            // React to the event
            Console.WriteLine($"Shipping Service: Preparing shipment for Order {order.Id}");
        });
    }
}        

  • PlaceOrder: Publishes an event after basic processing.
  • ShippingService: Listens for the “NewOrderPlaced” event and reacts when it happens.

Ready to dive deeper into Event-Driven Architecture?

Comment below or send me a message, and let’s figure out if EDA is right for your project.

Don’t forget to like, share, and follow for more tech tips!

要查看或添加评论,请登录

Dipak Pakhale的更多文章

社区洞察

其他会员也浏览了