<!-- mobian-agent-page publisher="dailydev" canonical="https://daily.dev/posts/when-to-use-microservices-and-when-not-to-in-net-bexpylmbp" -->

---
title: When to Use Microservices (And When Not To) in .NET
description: A practical decision guide on when microservices are justified versus when a modular monolith is the better choice, specifically for .NET teams. Microservices...
canonical: https://daily.dev/posts/when-to-use-microservices-and-when-not-to-in-net-bexpylmbp
twitter:card: summary_large_image
twitter:site: @dailydotdev
og:type: website
og:site_name: daily.dev
og:title: When to Use Microservices (And When Not To) in .NET | daily.dev
og:description: A practical decision guide on when microservices are justified versus when a modular monolith is the better choice, specifically for .NET teams. Microservices...
og:url: https://daily.dev/posts/when-to-use-microservices-and-when-not-to-in-net-bexpylmbp
og:image: https://api.daily.dev/og/posts/bExpylMbP.png
og:image:alt: When to Use Microservices (And When Not To) in .NET
og:image:width: 1200
og:image:height: 630
og:locale: en
---

> ## Documentation Index
> Fetch the complete documentation index at: https://daily.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# When to Use Microservices (And When Not To) in .NET

**[Code with Mukesh](https://daily.dev/sources/codewithmukesh)** · [@iammukeshm](https://daily.dev/iammukeshm) · 18 min read · 12 upvotes · 0 comments

## Summary

A practical decision guide on when microservices are justified versus when a modular monolith is the better choice, specifically for .NET teams. Microservices primarily solve organizational and scaling problems — not code quality issues — and are only worth the operational cost when multiple teams block each other on deploys, one component has wildly different scaling needs, or strict isolation requirements exist. The hidden costs include distributed data consistency (sagas), harder debugging requiring distributed tracing, complex local dev setups, and per-service CI/CD pipelines. For most teams, a modular monolith delivers clean internal boundaries with none of the network overhead, and keeps the option to extract services later. Real-world examples from Amazon Prime Video (90% cost reduction after consolidating to a monolith) and Segment's 'Goodbye Microservices' retrospective reinforce the case. A decision matrix maps team size and situation to the recommended architecture.

## Full article

daily.dev links to this article rather than hosting it. Read it at the original source: <https://codewithmukesh.com/blog/when-to-use-microservices>

## Questions this post answers

### Why did Amazon Prime Video move their video quality monitoring service from microservices back to a monolith?

Amazon Prime Video rebuilt its audio/video quality monitoring service in 2023, moving it from a distributed serverless design using AWS Step Functions and Lambda functions into a single monolithic process. The original architecture hit scaling limits and became expensive due to orchestration overhead and the cost of moving data between components. Consolidating into one process cut infrastructure cost by roughly 90 percent and improved scalability for that workload.

_Weighing a similar consolidation for a serverless pipeline is easier with real cost-comparison stories surfaced on daily.dev._

### Why did Segment abandon their microservices architecture?

Segment, a customer-data platform, scaled to over 140 microservices and found the operational overhead of per-service deploys, dependency management, and cognitive load was crushing their small team's velocity, as described in their retrospective titled Goodbye Microservices. They consolidated back into a single monolith and saw a significant productivity boost, concluding microservices were the wrong tool for their team size and problem shape rather than being inherently bad.

_Teams sizing their own service count against team size can compare real-world postmortems like this on daily.dev._

### Does each microservice need its own database?

Yes, database-per-service is a defining, non-negotiable rule of microservices architecture. If two services share a database, they become coupled at the schema level and can no longer be deployed or evolved independently, eliminating the architecture's main benefit. Owning a private database also forces eventual consistency, requiring patterns like sagas instead of a single ACID transaction across services.

_Developers designing service boundaries can weigh trade-offs like database-per-service against alternatives on daily.dev._

## Similar posts on daily.dev

- [Monolith vs Microservices in C\#: A Decision Framework for .NET Developers](https://daily.dev/posts/monolith-vs-microservices-in-c-a-decision-framework-for-net-developers-mtiae4sfc) · We Are .NET · 0 upvotes · 0 comments
- [You Want Microservices—But Do You Need Them?](https://daily.dev/posts/you-want-microservices-but-do-you-need-them--rxvxkwg2c) · Docker · 150 upvotes · 11 comments
- [From Microservices Back to Monolith in C\#: When and How to Reverse Course](https://daily.dev/posts/from-microservices-back-to-monolith-in-c-when-and-how-to-reverse-course-b2t5nhtne) · We Are .NET · 1 upvotes · 0 comments
- [Microservices vs Monolithic Architecture: What Nobody Tells You Until You've Lived Through Both](https://daily.dev/posts/microservices-vs-monolithic-architecture-what-nobody-tells-you-until-you-ve-lived-through-both-sju1wi5pt) · SitePoint · 41 upvotes · 10 comments
- [The Microservice That Should Have Been a Function, CodeGood](https://daily.dev/posts/the-microservice-that-should-have-been-a-function-codegood-l8ycqeu1k) · CodeGood · 1 upvotes · 0 comments

---

Tags: [#architecture](https://daily.dev/tags/architecture), [#microservices](https://daily.dev/tags/microservices), [#distributed-systems](https://daily.dev/tags/distributed-systems), [#domain-driven-design](https://daily.dev/tags/domain-driven-design)

[View this post on daily.dev](https://daily.dev/posts/when-to-use-microservices-and-when-not-to-in-net-bexpylmbp)

```json
{"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]}
{"@context":"https://schema.org","@type":"TechArticle","headline":"When to Use Microservices (And When Not To) in .NET","url":"https://daily.dev/posts/when-to-use-microservices-and-when-not-to-in-net-bexpylmbp","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/when-to-use-microservices-and-when-not-to-in-net-bexpylmbp"},"datePublished":"2026-07-31T06:32:33.400Z","dateModified":"2026-09-14T07:00:22.789Z","description":"A practical decision guide on when microservices are justified versus when a modular monolith is the better choice, specifically for .NET teams. Microservices...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/092303c7eedc8965bdf2bbcae19b2105?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/092303c7eedc8965bdf2bbcae19b2105?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Code with Mukesh","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Person","name":"Mukesh Murugan","url":"https://daily.dev/iammukeshm","image":"https://lh3.googleusercontent.com/a-/AFdZucr2UBIpOeVTWohK8XKuXPOutNG6hgyQMz7CYj7LEA=s100","interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"EndorseAction"},"userInteractionCount":790}},"commentCount":0,"discussionUrl":"https://daily.dev/posts/when-to-use-microservices-and-when-not-to-in-net-bexpylmbp","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":12},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"architecture,microservices,distributed-systems,domain-driven-design","timeRequired":"PT18M"}
{"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Code with Mukesh","item":"https://daily.dev/sources/codewithmukesh"},{"@type":"ListItem","position":3,"name":"When to Use Microservices (And When Not To) in .NET"}]}
{"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/when-to-use-microservices-and-when-not-to-in-net-bexpylmbp#faq","mainEntity":[{"@type":"Question","name":"Why did Amazon Prime Video move their video quality monitoring service from microservices back to a monolith?","acceptedAnswer":{"@type":"Answer","text":"Amazon Prime Video rebuilt its audio/video quality monitoring service in 2023, moving it from a distributed serverless design using AWS Step Functions and Lambda functions into a single monolithic process. The original architecture hit scaling limits and became expensive due to orchestration overhead and the cost of moving data between components. Consolidating into one process cut infrastructure cost by roughly 90 percent and improved scalability for that workload. Weighing a similar consolidation for a serverless pipeline is easier with real cost-comparison stories surfaced on daily.dev."}},{"@type":"Question","name":"Why did Segment abandon their microservices architecture?","acceptedAnswer":{"@type":"Answer","text":"Segment, a customer-data platform, scaled to over 140 microservices and found the operational overhead of per-service deploys, dependency management, and cognitive load was crushing their small team's velocity, as described in their retrospective titled Goodbye Microservices. They consolidated back into a single monolith and saw a significant productivity boost, concluding microservices were the wrong tool for their team size and problem shape rather than being inherently bad. Teams sizing their own service count against team size can compare real-world postmortems like this on daily.dev."}},{"@type":"Question","name":"Does each microservice need its own database?","acceptedAnswer":{"@type":"Answer","text":"Yes, database-per-service is a defining, non-negotiable rule of microservices architecture. If two services share a database, they become coupled at the schema level and can no longer be deployed or evolved independently, eliminating the architecture's main benefit. Owning a private database also forces eventual consistency, requiring patterns like sagas instead of a single ACID transaction across services. Developers designing service boundaries can weigh trade-offs like database-per-service against alternatives on daily.dev."}}]}
```

