TL;DR
- Start with a well-structured monolith for most new products: it ships faster and costs less.
- Move to microservices when you have clear scaling pressure, multiple autonomous teams, or wildly different per-component scaling needs.
- Use the strangler fig pattern to migrate incrementally: never attempt a big-bang rewrite.
- Microservices add roughly £20k–£40k in upfront complexity and 20–40% higher cloud costs.
- Event-driven architecture is a powerful middle ground worth considering before committing to full microservices.
What Is a Monolithic Architecture?
A monolith is a software application where all components, the user interface, business logic, and data access layer, are built and deployed as a single, unified unit. When you deploy, you deploy everything at once. When one part crashes badly enough, everything goes down with it.
Despite the negative connotations the word has picked up in recent years, monoliths have powered some of the most successful companies in the world. Shopify, Stack Overflow, and Basecamp all scaled to enormous traffic on a monolith. Many UK fintechs and US SaaS businesses serving thousands of customers run entirely monolithic systems with no practical reason to change.
Advantages of a Monolith
- Simplicity: One codebase, one repository, one deployment pipeline. Developers in London, Toronto, or Sydney can clone and run the entire application in minutes.
- Lower initial cost: No service discovery, no distributed tracing setup, no API gateway to manage. A small team can build and ship faster.
- Single deployment: Atomic deployments mean no version mismatch issues between services: a constant headache in distributed systems.
- Easier debugging: Stack traces are contained within a single process. Tools like a debugger or a profiler work straightforwardly.
- Great for MVPs: When you're validating a business idea, every week counts. A monolith lets you iterate quickly without distributed systems overhead.
- In-process calls: Function calls are orders of magnitude faster than network calls. Performance can actually be superior to microservices for many workloads.
- ACID transactions: Database transactions spanning multiple domain entities are trivial in a monolith. Distributed transactions in microservices require sagas or two-phase commit: both complex and error-prone.
What Is a Microservices Architecture?
A microservices architecture decomposes the application into a collection of small, independently deployable services, each responsible for a specific business capability. A typical e-commerce platform might have separate services for: user authentication, product catalogue, inventory, orders, payments, notifications, and search.
Each service owns its own data store, exposes an API (REST, gRPC, or event-based), and can be deployed, scaled, and updated independently. Teams in the US working on the payment service don't need to coordinate release windows with teams in Canada working on the notification service.
Advantages of Microservices
- Independent scalability: Scale only the services that need it. During a peak sale event in Australia, you can scale the product catalogue and checkout services without touching authentication.
- Technology flexibility: Different services can use different languages and databases. Use Python for ML-heavy services, Go for high-throughput APIs, and Node.js for real-time features: all within the same system.
- Team autonomy: Each team owns its service end-to-end, enabling truly independent delivery pipelines. No cross-team merge conflicts, no shared deployment windows.
- Fault isolation: A bug in the recommendation service won't bring down checkout. This resilience is critical for high-availability platforms in regulated industries.
- Faster iteration per service: Small codebases are easier to understand, test, and refactor. Onboarding a new developer to a 3,000-line service is vastly easier than onboarding to a 300,000-line monolith.
- Independent deployments: Multiple deployments per day per service become practical, enabling genuine continuous delivery.
10-Dimension Comparison: Monolith vs Microservices
| Dimension | Monolith | Microservices |
|---|---|---|
| Initial development speed | Fast: single codebase, no inter-service wiring | Slower: service boundaries, APIs, and infrastructure must be designed upfront |
| Scalability | Scale the entire application: inefficient at high scale | Scale individual services independently: highly efficient |
| Deployment complexity | Simple: one artifact, one pipeline | High: each service has its own pipeline, container image, and deployment config |
| Fault isolation | Poor: a critical bug can take down everything | Excellent: failures are contained to individual services |
| Technology flexibility | Limited: typically locked to one stack | High: each service can use the best-fit language and database |
| Testing | Unit and integration tests are straightforward | Requires contract testing, integration environments, and careful test orchestration |
| Team structure fit | Best for small, co-located or tightly coordinated teams (2–15 engineers) | Best for large organisations with multiple autonomous teams (15+ engineers) |
| Operational overhead | Low: minimal DevOps tooling required | High: requires service mesh, API gateway, distributed tracing, orchestration |
| Data management | Single database: easy ACID transactions | Distributed data: sagas, eventual consistency, complex cross-service queries |
| Upfront cost | Lower: less infrastructure to provision and manage | £20k–£40k additional complexity cost vs equivalent monolith |
When Monolith Wins
The monolith is the right choice, and often the only sensible one, in the following situations:
Early-Stage Startups
Whether you're building a SaaS product in Manchester, a marketplace in Toronto, or an enterprise tool in Sydney, the single most important thing at the start is speed of iteration. A monolith lets a team of two to five developers focus entirely on product rather than infrastructure. Companies like GitHub, Twitter, and Airbnb all started as monoliths. They only moved to microservices after proving product-market fit and experiencing genuine scaling pain.
Small Teams
Conway's Law states that organisations build systems that mirror their communication structure. A five-person engineering team working on twenty microservices will spend more time on coordination overhead than on features. The cognitive load of owning multiple independently deployed services crushes small teams. A single, well-modularised codebase is the better choice.
Low Complexity or Stable Domains
If your application serves a well-understood, stable domain with predictable load patterns, the complexity of microservices delivers no practical benefit. Examples include an internal HR tool for a European company or a reporting dashboard for a US professional services firm. The uniformity of load and the stability of requirements make a monolith not just acceptable, but actively superior.
Budget-Constrained Projects
For a business needing a custom software solution delivered within a defined budget, a monolith will typically deliver far more features for the same spend. Many UK SMEs and Australian mid-market companies benefit greatly from a well-built monolith that can be extended for years without architectural change.
When Microservices Wins
Scale requirements: When different components of your system have dramatically different traffic patterns, microservices let you scale each component independently. For example, a product search service might handle 50,000 requests per second while an admin dashboard handles 100. This is why Netflix, Amazon, and Uber operate microservices at thousands of individual services.
Multiple autonomous teams: When you have 30+ engineers working across the same codebase, coordination overhead becomes the bottleneck. Microservices, aligned to team ownership along domain boundaries (the so-called "you build it, you run it" model), unlock truly parallel delivery. Teams across UK, US, and Canada offices can release independently without blocking each other.
Different technology needs per domain: If your recommendation engine needs Python and PyTorch, your real-time notification system needs Go, and your payment service needs Java with strict compliance tooling, microservices let each team use the best tool for their domain. That beats compromising on a single shared stack.
Regulatory or compliance isolation: In the UK financial sector, certain data and processes must be kept strictly separated. Microservices with well-defined boundaries and separate data stores make compliance with FCA requirements, GDPR, and PCI-DSS more tractable. That is far easier than enforcing data isolation within a shared database schema.
The Strangler Fig Pattern: Migrating from Monolith to Microservices
The strangler fig pattern is named after the strangler fig tree, which grows around a host tree until the host is completely replaced. It is the industry-standard approach for transitioning from a monolith to microservices without a big-bang rewrite.
The Strangler Fig Migration Steps
- Identify the right service to extract first. Choose a well-bounded domain that changes frequently or has distinct scaling needs. Avoid starting with shared infrastructure like authentication.
- Place a facade or API gateway in front of the monolith. All traffic continues to route to the monolith, but you now control the routing layer. Tools like AWS API Gateway, Kong, or Nginx serve this purpose well.
- Build the new microservice in parallel. Build the new service independently, with its own data store, deployment pipeline, and tests.
- Migrate traffic gradually. Begin by routing new requests for that domain to the new service. Use feature flags to control the rollout. Monitor closely for errors and latency regressions.
- Synchronise data and remove the monolith code path. Once the new service handles all traffic for its domain, delete the corresponding code from the monolith and migrate the data.
- Repeat. Extract the next service. Over months or years, the monolith shrinks until it can be decommissioned entirely.
Warning: Never attempt a big-bang rewrite: rewriting the entire application from scratch as microservices simultaneously. This approach has a near-100% failure rate for complex systems. The strangler fig pattern is the only proven safe approach to this migration. It still requires careful planning, strong testing, and disciplined execution over 12–36 months for a mid-sized system.
Docker and Kubernetes in a Microservices Context
Docker containers are the standard packaging format for microservices. Each service is packaged as a container image with all its dependencies. This eliminates "works on my machine" problems across development environments in the UK office and production environments in AWS US East. Key Docker best practices for microservices include:
- Use multi-stage builds to keep production images small (often 10x smaller than naive builds)
- Run containers as non-root users for security
- Use Alpine or Distroless base images to minimise attack surface
- Never bake secrets into images: inject via environment variables or a secrets manager
- Tag images with the Git commit SHA for full traceability
Kubernetes (K8s) is the de-facto standard for orchestrating containerised microservices at scale. It handles:
- Deployments: Declarative rolling updates with automatic rollback on failure
- Services: Internal DNS-based service discovery: no hardcoded IPs
- Ingress: External HTTP routing with TLS termination
- Horizontal Pod Autoscaler (HPA): Automatically scales pods based on CPU, memory, or custom metrics
- ConfigMaps and Secrets: Externalised configuration management
- Namespaces: Logical isolation between teams or environments (dev, staging, production)
Service Mesh: Managing Communication at Scale
As the number of microservices grows, managing communication between them becomes complex. A service mesh (such as Istio or Linkerd) provides a dedicated infrastructure layer for service-to-service communication, handling:
Traffic Management
Canary releases, circuit breaking, retries, and timeouts: all configurable without changing application code
mTLS Security
Mutual TLS between all services: ensuring encrypted, authenticated communication across the entire mesh
Observability
Automatic distributed tracing and metrics for every service call: without instrumentation code in the application
Event-Driven Architecture: The Middle Ground
Before committing to a full microservices architecture, many teams benefit from adopting an event-driven architecture (EDA) within a modular monolith. Instead of direct function calls between modules, modules communicate via an internal event bus. This decouples components without the operational overhead of separate deployments.
When you're ready to extract a service, the event-based interface you've already defined makes the extraction far cleaner. You simply move the event consumer to a new service and route events through an external message broker like Apache Kafka, AWS SNS/SQS, or RabbitMQ.
EDA is particularly well-suited to workflows with asynchronous processing needs, such as order fulfilment, document processing, and notification pipelines. These are common in UK e-commerce, Canadian healthcare platforms, and Australian logistics software.
Cost Implications: What Microservices Actually Cost
Upfront Complexity Cost: £20,000–£40,000
This covers the additional engineering effort to:
- design service boundaries
- set up a Kubernetes cluster (managed services like EKS, GKE, or AKS reduce this)
- configure an API gateway
- implement distributed tracing (Jaeger, Zipkin, or Datadog APM)
- establish individual CI/CD pipelines per service
For a team building the same feature set, microservices consistently cost 30–60% more to build initially.
Ongoing Infrastructure Cost: 20–40% Higher
Running fifteen services each with their own minimum compute allocation costs significantly more than a single application server with the same aggregate resources. Load balancers, managed Kubernetes control planes, and inter-service data transfer fees add up. A monolith serving 10,000 users might cost £500/month on cloud infrastructure. Equivalent microservices might cost £700–£900/month minimum.
Real-World Note for UK and European Teams: Many businesses are sold on microservices by consultancies and vendors because it generates more billable work. Unless you genuinely have the scaling requirements or team size that justifies it, a well-architected modular monolith on a managed cloud service (AWS Elastic Beanstalk, Heroku, Render, or Railway) is a better bet. It will serve you for years at a fraction of the cost and operational burden.
Real-World Architecture Decisions: UK, US, Canada, Europe, Australia
UK Fintech Startup: Monolith to Microservices Journey
A London-based payments startup launched with a Django monolith. For the first 18 months, the team of six shipped features weekly without any architecture concerns. At £2M ARR and 40 engineers across UK and Poland offices, deployment coordination became the main bottleneck. They used the strangler fig pattern to extract the payments processing service first, followed by the KYC verification service. Today they run eight microservices. They kept the admin and reporting modules as a monolith. There was no business case to split them.
Australian SaaS Platform: Staying with the Monolith
A Melbourne-based workforce management SaaS serves the healthcare sector in Australia, New Zealand, and Canada. The company built its initial version as a Ruby on Rails monolith. After five years and 500+ enterprise clients, they have resisted microservices migration. Their engineering team of twelve is highly productive, their deployment pipeline is simple, and their cloud costs are predictable. They've invested instead in a modular internal architecture, thorough test coverage, and a robust CI/CD pipeline. This achieves 99.95% uptime without the complexity of distributed systems.
Making the Decision: A Framework
Answer these questions honestly:
- Do different parts of my system have meaningfully different scaling requirements? (If no → monolith)
- Do I have more than 20 engineers actively working on this system? (If no → monolith)
- Are deployment conflicts between teams causing real slowdowns? (If no → monolith)
- Do I need different technology stacks for different domains? (If no → monolith)
- Do I have dedicated DevOps/platform engineering capacity? (If no → monolith)
- Is my domain well-understood enough to define stable service boundaries? (If no → modular monolith first)
If you answered "yes" to three or more of these, and you have the operational maturity to support it, microservices may be the right path. Otherwise, invest in a well-structured monolith and keep the option to migrate open.