The microservices hype tax
Every year teams split a working monolith into fifteen repositories, add Kubernetes, and wonder why feature velocity dropped. Microservices with .NET are a valid choice when organizational and technical pressures align—not when a conference slide said Netflix does it. Toolliyo's microservices tutorials sit next to modular monolith guidance because hiring managers want you to articulate trade-offs, not parrot "microservices are modern."
What microservices actually mean
Independently deployable services with their own data stores, communicating over network protocols (HTTP/gRPC/message buses), owned by teams that can release without coordinating a monolith deploy. If you share one database with foreign keys across services, you likely have a distributed monolith—worse than before.
Signals you might need services
- Different scaling profiles: image processing vs catalog API.
- Distinct release cadences: compliance service audited quarterly vs daily storefront changes.
- Polyglot requirements rare in pure .NET shops but real for ML inference sidecars.
- Team topology (Conway's law): autonomous teams need hard boundaries.
- Fault isolation: failure in recommendations must not take down checkout—when business accepts partial degradation.
Signals you should stay modular monolith first
- One small team under ten engineers.
- Unclear domain boundaries still shifting weekly.
- No mature CI/CD, observability, or on-call rotation.
- Transactions across features are overwhelmingly ACID today.
- You are rewriting to escape debt without fixing modeling—splitting spaghetti into networked spaghetti.
.NET tooling that makes services viable
ASP.NET Core minimal APIs and gRPC for fast inter-service calls. Worker Services for background consumers. MassTransit or Azure Service Bus for messaging. YARP as reverse proxy. OpenTelemetry exporters. Health checks and Polly for resilience. EF Core per service database—no shared DbContext across boundaries.
Data ownership and the hardest problem
Each service owns its schema. Cross-service queries become API composition or read models maintained via events. Saga patterns or outbox for distributed transactions replace a single BEGIN TRANSACTION. Example: Order service publishes OrderPlaced; Inventory reserves stock asynchronously. You must design compensating actions when reserve fails after payment captured.
Communication styles
Sync HTTP/gRPC: simple mental model, coupling on availability—use for queries needing immediate consistency with timeouts and retries idempotently. Async messaging: better for fan-out, buffering, temporal decoupling—requires handling duplicates and ordering. Most mature systems mix both deliberately.
Observability is non-optional
Distributed tracing with trace ids propagated from gateway through calls. Structured logging with correlation. Metrics per service (rate, errors, duration). Without this, debugging latency means guessing. Budget for a platform team or managed cloud services (Application Insights, Grafana Cloud) before splitting the monolith.
API gateway and BFF patterns
Public clients talk to a gateway or Backend-for-Frontend tailored to web vs mobile shapes. Internal services stay private in a network mesh or private VNet. Do not expose every microservice endpoint directly to the internet.
Deployment and environments
Independent deploys need contract tests and backward-compatible schema evolution. Feature flags help. Blue/green or canary per service reduces blast radius. Version APIs; avoid breaking consumers on Friday deploys.
Organizational cost nobody tweets about
More repos, more pipelines, more staging matrices, more on-call rotations, more cross-team meetings for contract changes. If leadership will not fund that tax, microservices will frustrate developers.
Strangler fig migration path
Extract the highest-churn or highest-risk domain first—notifications, search—not the core ledger on day one. Run dual-write or event sync temporarily; measure error budgets. Keep monolith features working until cutover proven.
Interview answers that sound senior
"We chose a modular monolith with clear bounded contexts in one solution because team size is six and deploy frequency is daily—extracting catalog search is planned when Elasticsearch expertise joins." That beats "microservices because scalable" without metrics.
Study path on Toolliyo
Learn Docker and health checks, then messaging basics, then one extracted service from a sample monolith with integration tests and traces you can screenshot. Document failure modes you tested—timeouts, duplicate messages, partial outages.
Microservices with .NET are powerful when boundaries match business capability and operations maturity. Default to a well-structured monolith, earn distribution by pain points you can name, and deploy services when autonomy and scale genuinely outweigh coordination overhead.