--- title: Pragmatic Architecture: Finding Your Architectural Compass description: An engineer argues that architecture decisions should be driven by a system's actual operational needs rather than industry trends, whether that trend is... canonical: https://daily.dev/posts/pragmatic-architecture-finding-your-architectural-compass-5hqapopaq twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Pragmatic Architecture: Finding Your Architectural Compass | daily.dev og:description: An engineer argues that architecture decisions should be driven by a system's actual operational needs rather than industry trends, whether that trend is... og:url: https://daily.dev/posts/pragmatic-architecture-finding-your-architectural-compass-5hqapopaq og:image: https://api.daily.dev/og/posts/5HqaPopaQ.png og:image:alt: Pragmatic Architecture: Finding Your Architectural Compass 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. # Pragmatic Architecture: Finding Your Architectural Compass **[iO tech\_hub](https://daily.dev/sources/iotechhub)** · 10 min read · 4 upvotes · 0 comments ## Summary An engineer argues that architecture decisions should be driven by a system's actual operational needs rather than industry trends, whether that trend is 'microservices-first' or the current backlash toward 'monolith-first'. Using a real example of five services (four adapters plus one domain service), the piece shows how differing traffic profiles, external-dependency risk, and blast-radius isolation justified splitting services, while cautioning against splitting by nouns (premature decomposition) which leads to distributed monoliths. It closes by noting that AI coding agents make building services trivial but don't remove the need for sound architectural judgment about boundaries, scaling, and failure isolation. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### When does it make sense to split a system into microservices instead of using a modular monolith? Splitting into separate services makes sense when components have materially different operational characteristics, such as needing to scale independently, having a different reliability or deployment profile, or depending on an external system whose failures shouldn't spread. In one real example, four adapter services handling different third-party APIs were split from a domain service because one adapter handled roughly 75% of traffic and needed independent scaling, and external API failures needed to stay isolated from core business logic. _Developers weighing monolith versus microservices trade-offs can find grounded architecture takes like this on daily.dev._ ### What is a distributed monolith and how does it happen? A distributed monolith happens when a system is split into services by domain nouns, like Customer Service, Order Service, or Payment Service, but those services still must deploy together, communicate constantly, share a database, and scale together. The result looks like microservices on a diagram but behaves like a monolith with worse deployment and debugging experience, because the boundaries were drawn by vocabulary instead of by operational differences. _Engineers debugging tangled service boundaries can track pragmatic architecture guidance on daily.dev._ ## Similar posts on daily.dev - [Modular Monolith and Microservices: Modularity is what truly matters](https://daily.dev/posts/modular-monolith-and-microservices-modularity-is-what-truly-matters-alztxj5cq) · Hacker News · 28 upvotes · 1 comments --- Tags: [#career](https://daily.dev/tags/career), [#architecture](https://daily.dev/tags/architecture), [#microservices](https://daily.dev/tags/microservices), [#distributed-systems](https://daily.dev/tags/distributed-systems) [View this post on daily.dev](https://daily.dev/posts/pragmatic-architecture-finding-your-architectural-compass-5hqapopaq) ```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":"Pragmatic Architecture: Finding Your Architectural Compass","url":"https://daily.dev/posts/pragmatic-architecture-finding-your-architectural-compass-5hqapopaq","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/pragmatic-architecture-finding-your-architectural-compass-5hqapopaq"},"datePublished":"2026-09-01T08:47:24.259Z","dateModified":"2026-09-01T08:49:04.357Z","description":"An engineer argues that architecture decisions should be driven by a system's actual operational needs rather than industry trends, whether that trend is...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/adb2dbf2c383df7971358846f63d3157?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/adb2dbf2c383df7971358846f63d3157?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"iO tech_hub","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":"Organization","name":"iO tech_hub","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1/logos/ac540f589d8843d99692bd6368ee7680","url":"https://daily.dev/sources/iotechhub"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/pragmatic-architecture-finding-your-architectural-compass-5hqapopaq","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":4},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"career,architecture,microservices,distributed-systems","timeRequired":"PT10M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"iO tech_hub","item":"https://daily.dev/sources/iotechhub"},{"@type":"ListItem","position":3,"name":"Pragmatic Architecture: Finding Your Architectural Compass"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/pragmatic-architecture-finding-your-architectural-compass-5hqapopaq#faq","mainEntity":[{"@type":"Question","name":"When does it make sense to split a system into microservices instead of using a modular monolith?","acceptedAnswer":{"@type":"Answer","text":"Splitting into separate services makes sense when components have materially different operational characteristics, such as needing to scale independently, having a different reliability or deployment profile, or depending on an external system whose failures shouldn't spread. In one real example, four adapter services handling different third-party APIs were split from a domain service because one adapter handled roughly 75% of traffic and needed independent scaling, and external API failures needed to stay isolated from core business logic. Developers weighing monolith versus microservices trade-offs can find grounded architecture takes like this on daily.dev."}},{"@type":"Question","name":"What is a distributed monolith and how does it happen?","acceptedAnswer":{"@type":"Answer","text":"A distributed monolith happens when a system is split into services by domain nouns, like Customer Service, Order Service, or Payment Service, but those services still must deploy together, communicate constantly, share a database, and scale together. The result looks like microservices on a diagram but behaves like a monolith with worse deployment and debugging experience, because the boundaries were drawn by vocabulary instead of by operational differences. Engineers debugging tangled service boundaries can track pragmatic architecture guidance on daily.dev."}}]} ```