Building Microservices with .NET
Building Microservices with .NET is a course in designing and building microservice systems with .NET 10 and ASP.NET Core, from drawing service boundaries and communicating over HTTP, gRPC and RabbitMQ to handling transactions with sagas, testing and running everything with Aspire. It suits developers with C# experience and software architects who shape how systems are structured.
- Duration18 hours · 3 days
- FormatOnsite / live online
- Next roundOn request
- CertificateIncluded
Course overview
Microservices split a large system into smaller services that can be developed, deployed and scaled independently. Each service owns its database and talks to others through APIs or messages. Teams can work in parallel and change one part at a time, but this comes with the complexity of distributed systems: services that fail in a chain reaction, data that drifts out of sync between services, and problems that are hard to trace across many services. Many teams split too early and end up with a system that is harder to run than the original monolith.
This course shows learners how to design and build microservices with .NET 10 and ASP.NET Core 10. It starts with deciding when to split a system, drawing service boundaries with DDD and building services that own their data, then composes and runs the whole system with Aspire. Learners practise communication over HTTP, gRPC and messages through RabbitMQ, add resilience, handle cross-service transactions with sagas and the outbox pattern, put an API gateway in front with YARP, apply event sourcing and CQRS, handle security and observability with OpenTelemetry, and test with xUnit and Testcontainers. The course closes with container builds and a microservices store capstone. (3 days, 6 hours per day, 18 hours in total, Intermediate level.)
What you’ll gain
- Decide when microservices make sense and when a modular monolith is the better fit
- Draw service boundaries with DDD and design a database per service
- Build services with ASP.NET Core 10 and run the whole system with Aspire
- Connect services over HTTP, gRPC and RabbitMQ messaging, with resilience
- Handle cross-service transactions with sagas and the outbox pattern
- Apply event sourcing, CQRS and an API gateway where they fit
- Observe the system with OpenTelemetry and test microservices at several levels
- Build services as containers and prepare deployment with Docker Compose
Who this course is for
- .NET and C# developers who want to design microservice systems
- Developers who maintain large monoliths and are considering splitting them
- Software architects and tech leads who make architecture decisions
- DevOps teams who deploy and monitor systems made of many services
- Teachers, lecturers and computing students interested in modern software architecture
Prerequisites
- Solid C# skills and experience building web APIs with ASP.NET Core
- Familiarity with relational databases, SQL and basic Entity Framework Core
- Understanding of HTTP, JSON and RESTful API principles
- Basic Docker and Git experience
- A laptop with at least 16 GB of RAM that can run the .NET 10 SDK and Docker Desktop, with permission to install software
Curriculum
Course Details
This course is the 2026 edition that replaces the previous Building Microservices with .NET course, which was taught on .NET Core. It has been rewritten for .NET 10 (LTS), ASP.NET Core 10 and Aspire 13. It runs for 3 days, 6 hours per day (18 hours in total, 09:00-16:00), as lectures with labs built on a single sample store that is gradually split into services. Intermediate level. It keeps the original topics of splitting a system, communication, transactions, event sourcing, querying, external API integration, testing and container builds, and adds the modular monolith, Aspire, gRPC, resilience, RabbitMQ, sagas and the outbox pattern, YARP and OpenTelemetry. Learners take home a lab guide, source code for every lab and docker-compose files.
Day 1 Designing and Building the First Services
Section 1: Lab: Setting Up .NET 10 and Aspire
- An overview of .NET 10 (LTS), C# 14 and ASP.NET Core 10
- Install the .NET 10 SDK, Docker Desktop and the Aspire CLI
- Create a solution with aspire new and meet the AppHost and ServiceDefaults
- Explore the Aspire Dashboard: resources, logs, traces and metrics
- Lab: run a first sample system with aspire run
Section 2: Monolith, Modular Monolith and Microservices
- The benefits of microservices and the costs that are often overlooked
- Why a modular monolith is a safer starting point for many teams
- Signs that it is time to split a service, and signs that it is not
- The challenges of distributed systems: network, latency and consistency
Section 3: Splitting a System into Services with DDD
- Bounded contexts and ubiquitous language
- Aggregates and placing business logic in the right service
- Database per service, and why databases should not be shared
- Workshop: split a store into Catalog, Ordering and Payment services
Section 4: Lab: Building Services with ASP.NET Core 10
- Build a Catalog service with minimal APIs and built-in OpenAPI documentation
- Manage data with EF Core 10, PostgreSQL and migrations
- Validation, Problem Details and a standard error format
- Health checks and configuration for each service
- Lab: build Catalog and Ordering services with separate databases
Section 5: Lab: Composing the System with Aspire
- Declare resources in the AppHost with AddProject and AddPostgres
- Pass connection strings and endpoints with WithReference
- Service discovery between services without hard-coded URLs
- Aspire hosting integrations and client integrations
- Lab: run every service and database with a single command
Day 2 Communication Between Services
Section 6: Synchronous Communication
- Call other services with typed HttpClient and service discovery
- gRPC for fast internal communication
- Choosing between REST and gRPC, and versioning contracts
- Lab: the Ordering service checks product prices from Catalog over gRPC
Section 7: Lab: Resilience and External API Integration
- Timeouts, retries and circuit breakers with Microsoft.Extensions.Http.Resilience
- The standard resilience handler and tuning it for each destination
- Idempotency so that calls can be repeated safely
- Integrate external APIs, such as a simulated payment gateway
- Lab: shut down a downstream service and observe how the system behaves
Section 8: Lab: Asynchronous Messaging with RabbitMQ
- Commands versus events, and publish/subscribe
- Add RabbitMQ to the AppHost and connect with the async RabbitMQ.Client 7
- Exchanges, queues, acknowledgements and dead letter queues
- An overview of other messaging libraries and their licensing terms
- Lab: send an OrderCreated event for the Payment service to process
Section 9: Cross-Service Transactions
- Why distributed transactions are avoided, and eventual consistency
- Choreography and orchestration sagas with compensation
- The outbox pattern to keep saved data and published events consistent
- Lab: an order saga that cancels the order when payment fails
Section 10: Lab: API Gateway with YARP
- The role of an API gateway and the backend for frontend pattern
- Add YARP to the AppHost and route requests to each service
- Authentication and rate limiting at the gateway
- Lab: expose the store to clients through a single gateway
Day 3 Data, Quality and Deployment
Section 11: Event Sourcing and CQRS
- The idea of event sourcing: storing events instead of the latest state
- Event stores, projections and building read models
- CQRS to separate writes from reads, and when it pays off
- Lab: keep order history with event sourcing on PostgreSQL
Section 12: Querying Across Services
- API composition to combine data from several services
- Build read models from events to reduce cross-service calls
- Distributed caching with Redis through Aspire
- Lab: an order summary page that combines data from Catalog and Ordering
Section 13: Security and Observability
- Authentication with JWT bearer tokens from an identity provider such as Keycloak
- Service-to-service authentication and secret management
- Logs, metrics and distributed tracing with OpenTelemetry
- Track down cross-service problems from traces in the Aspire Dashboard
Section 14: Lab: Testing Microservices
- Unit tests for business logic with xUnit
- Integration tests with WebApplicationFactory and Testcontainers for .NET
- Whole-system tests with Aspire.Hosting.Testing
- The idea of contract testing to stop API changes from breaking other services
Section 15: Workshop: Containers, Deployment and Capstone
- Build container images with dotnet publish, without writing a Dockerfile
- Generate a Docker Compose file from the AppHost with aspire publish
- An overview of deploying to Kubernetes or the cloud, and CI/CD
- Capstone: add a new service to the store with events, tests and traces
- Present the work and review the design together
Schedule & training options
For individuals — public rounds
No public rounds are open right now. Join the waiting list and we will contact you first when the next round opens, or ask us on LINE. Or call 02-570-8449 or 088-807-9770
For organisations — in-house / private
- Tailor the content to your team’s tools and projects
- Your dates, at your office or live online
- Quotation with tax ID for procurement
Instructors
Frequently asked questions
How do microservices differ from a monolithic architecture?
A monolith runs the whole application as one program that is deployed in one piece. It is easy to start with, but as it grows, changing one part means redeploying everything. Microservices split the system into small services along business boundaries, each with its own database, deployed and scaled independently, at the cost of more complex communication and data consistency. A middle path many teams choose is a modular monolith, with clear module boundaries from the start and services split out only when needed.
How can services in a microservices system communicate?
There are two main styles. Synchronous calls go directly over HTTP REST or gRPC and wait for a reply; they are easy to understand, but if the destination fails the caller is stuck too, so timeouts, retries and circuit breakers are needed. Asynchronous communication sends messages or events through a broker such as RabbitMQ or Azure Service Bus for other services to pick up, which reduces coupling and absorbs peak load better. Real systems usually combine both, depending on the job.
What is event sourcing?
Event sourcing stores data as the full sequence of events that happened, such as order created, item added and payment received, instead of only the latest state. The current state is rebuilt by replaying the events in order, which gives a complete audit trail and lets you build new views of the data later. It is often paired with CQRS, which separates writes from reads so queries stay fast, but it adds complexity, so it is best used only where history or auditability really matters.
Who is the Building Microservices with .NET course for, and what should I know beforehand?
It suits .NET developers who want to apply microservices in their own projects, teams that maintain large monoliths, software architects and tech leads, and teachers, lecturers and students interested in software architecture. You should have solid C# skills, have built web APIs with ASP.NET Core, be able to use databases and basic Entity Framework Core, and have some Docker experience.
What will I be able to do after the Building Microservices with .NET course?
You will be able to judge whether a system should be split into microservices yet, draw service boundaries with DDD, build services with ASP.NET Core 10 and run the whole system with Aspire, connect services over HTTP, gRPC and RabbitMQ with resilience, handle transactions with sagas and the outbox pattern, use event sourcing, CQRS and an API gateway, observe the system with OpenTelemetry, test services and build containers. Participants who complete the training receive a Certificate of Completion with its own number, which can be verified online.
Can the Building Microservices with .NET course be run in-house for our team?
Yes. It can be run in-house for your team, with examples adapted to your work, such as drawing boundaries for the part of your system the team is considering moving to microservices, or choosing a message broker that fits your environment. You can request a quotation from this page, or contact us on LINE @itgenius or by phone on 02-570-8449.