Why should you care?

SMS providers fail, rate-limit, and change APIs. Isolating notifications keeps checkout fast — fire-and-forget a message instead of waiting for Twilio inside Order API.

See it live — copy this example

Create a Web API project (dotnet new webapi), paste the code, then run dotnet run.

app.MapPost("/notifications/email", async (SendEmailDto dto, IEmailSender sender) =>
{
    await sender.SendAsync(dto.To, dto.Subject, dto.Body);
    return Results.Accepted();
});

// Later: consumer for OrderShippedEvent
public class OrderShippedConsumer : IConsumer<OrderShippedEvent>
{
    public async Task Consume(ConsumeContext<OrderShippedEvent> ctx) =>
        await _email.SendAsync(ctx.Message.Email, "Shipped!", $"Order {ctx.Message.OrderId}");
}

Run Example »

Edit the code and click Run — like W3Schools Try it Yourself.

What happened?

• HTTP endpoint works for testing.
• In production, Order publishes OrderShippedEvent; Notification consumes and sends email asynchronously.

Try it yourself

1. Create Notification.Api with POST /notifications/email (log to console first).
2. Call it manually from Postman after creating an order.
3. Log order id and message body — verify end-to-end flow on paper.
4. Change a string or route in the example and save — watch Swagger or the RabbitMQ Management UI update.
5. Break the code on purpose (remove a semicolon), read the error message, then fix it.

Remember

Notification = outbound messages only. Prefer async events over sync calls from Order. Failures here should not roll back paid orders.

Real-world: Swiggy delivery SMS

Rider picked up food → Delivery service publishes event → Notification sends SMS in under 2 seconds average, async from order path.

Outcome: Peak dinner hour does not block order creation when SMS vendor throttles.