Why should you care?

Monoliths are faster to build early. Microservices help when teams, traffic, or deploy schedules fight each other. Pick based on pain, not because a blog said Netflix.

See it live — copy this example

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

// Monolith — one ShopNest.Api, one database
app.MapPost("/checkout", async (CheckoutDto dto) =>
{
    // order + payment + inventory + email in one method
    return Results.Ok();
});

// Microservices — Order.Api only creates order; others react later
app.MapPost("/orders", async (CreateOrderDto dto, IOrderService orders) =>
{
    var id = await orders.CreateAsync(dto);
    return Results.Created($"/orders/{id}", new { id });
});

Run Example »

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

What happened?

• The monolith checkout does all steps in one place — easy to read, hard to scale.
• The microservice version creates an order only.
• Payment and inventory come in later lessons via events.

Try it yourself

1. Draw two boxes on paper: Monolith (1 app, 1 DB) vs Microservices (Order app + Payment app + 2 DBs).
2. List three pros and three cons for each — use your own words.
3. Create one Order.Api with a single POST /orders endpoint.
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

Monolith = one app; microservices = many small apps. Split when deploy independence or scale per area matters. Never split without a reason you can explain in one sentence.

Real-world: Swiggy order flow

Restaurant menu, rider tracking, and payment change at different speeds. Microservices let the restaurant team deploy promos without waiting for the payment team release train.

Outcome: Teams deploy independently. A payment bug fix ships in hours, not after a full monolith regression cycle.