Microservices vs Monolith: Which Architecture Is Right for Your Nigerian Business

The microservices debate has produced more architectural regret than almost any other technical fashion of the last decade. Teams adopted microservices because the architecture was pioneered by Netflix, Amazon, and Google — companies with thousands of engineers and billions of transactions per day — and concluded that the architecture appropriate for those organisations was appropriate for their thirty-person startup.

It was not. The costs of a distributed architecture are fixed regardless of traffic volume; the benefits only materialise at significant scale.

What the Terms Actually Mean

Monolith: A single deployable application containing all business logic. Not necessarily a big ball of mud — a well-structured monolith has clear module boundaries, separated concerns, and clean internal interfaces. The distinction is deployment: one application, deployed as one unit to one (or more, for redundancy) server.

Microservices: Multiple independently deployable services, each responsible for a specific bounded domain, communicating over a network (typically HTTP/REST or message queues). The services are independently scaled, independently deployed, and independently maintained.

Modular monolith (the often-overlooked middle ground): A single deployable application with strong internal module boundaries that can be extracted into separate services if and when scale or team topology demands it. This is the architecture that most businesses should start with.

The Real Costs of Microservices

The microservices benefits — independent scaling, independent deployment, technology diversity, fault isolation — are real but only accessible after paying significant operational costs. These costs are often underestimated at architecture decision time.

Distributed tracing and debugging: In a monolith, a request that produces an error shows a single stack trace locatable in one codebase. In a microservices architecture, a request that fails after passing through five services requires distributed tracing infrastructure (Jaeger, Zipkin, or a managed equivalent) to reconstruct the execution path. Teams that implement microservices without distributed tracing spend significantly longer debugging production issues than equivalent monolith teams.

Network failure complexity: A monolith makes function calls. Microservices make network calls. Network calls fail, time out, and produce partial results in ways that function calls do not. Every inter-service communication path requires explicit handling for: timeouts, retries with exponential backoff, circuit breaking (stopping retry storms against a failing service), and fallback behaviour. This complexity multiplies by the number of service-to-service communication paths. For ten services with each communicating with three others, that is thirty communication paths, each requiring this error handling.

Data consistency across services: A monolith typically operates on a single database and can use database transactions to ensure consistency across multiple operations. Microservices that own their data stores cannot use cross-service transactions. The distributed transaction problem is not fully solved; approaches like the Saga pattern introduce significant implementation complexity and operational risk.

Deployment overhead: Deploying a monolith is one deployment. Deploying ten microservices may require up to ten deployments, each with its own CI/CD pipeline, container registry, Kubernetes configuration, and health check. The infrastructure management overhead and the cognitive load of keeping dependency versions compatible across service boundaries is a real recurring cost.

Team alignment cost: The Conway's Law insight — that software architecture mirrors the communication structure of the organisations that build it — works in both directions. If your team of six engineers is maintaining twelve microservices, every feature that spans service boundaries requires cross-service coordination that would be unnecessary in a monolith. The architecture is fighting the team's natural working patterns.

The Benefits of Microservices (And When They Materialise)

These costs are justified when the benefits are real — which requires specific conditions:

Independent scaling: If your image processing service needs ten times more compute than your authentication service, and both are in the same monolith, scaling up requires scaling everything. As separate services, you scale only the resource-constrained component. This benefit is real but only materialises when different components of your application have materially different resource profiles — which is a traffic pattern that most applications do not exhibit until significant scale.

Independent deployment: If twenty engineers are working on the same codebase, deployments become coordination exercises. Blocking deployments while another team's feature is untested creates delivery friction. With microservices owned by separate teams, each team deploys independently. This benefit is largely irrelevant below fifteen to twenty engineers actively deploying.

Technology diversity: Different services can be written in different languages with different data stores. Useful when a specific problem is genuinely better solved by a technology that is incompatible with the rest of the stack. Rare in practice; the coordination cost of multi-language systems usually exceeds the benefit below large team sizes.

Fault isolation: A memory leak in one service does not crash the entire application. True, but a well-designed monolith with health checks and automatic restart handles many of the failure scenarios that microservices fault isolation addresses.

The Decision Framework

The evidence-based criteria for choosing microservices over a modular monolith:

Team size threshold: You have more than fifteen engineers actively engaging with the codebase, and different teams own distinguishable business domains. Below this threshold, the coordination overhead of microservices exceeds the independence benefit.

Traffic pattern evidence: You have measured (not projected) that specific components of your application need to scale independently because they have materially different resource utilisation. Scaling projections based on ambition rather than measurement are not sufficient.

Deployment frequency evidence: Deployment conflicts between teams are genuinely occurring and delaying delivery. This is verifiable in your deployment logs — not a concern about future hypothetical growth.

Operational capability: You have (or can hire) engineers with production experience operating distributed systems, including distributed tracing, service mesh configuration, and Kubernetes operations. A team that has never operated a Kubernetes cluster at scale should not adopt microservices architecture until that capability exists.

If fewer than three of these four criteria apply, the modular monolith is the right choice.

In our experience with Nigerian startups and mid-market businesses, the monolith-first approach almost always wins. We have seen companies spend six months building a microservices architecture for a product that had not yet proven product-market fit. A well-structured monolith shipped in eight weeks would have given them the same outcome and left the microservices migration for when they actually needed it. The decision to go monolith-first is not a concession — it is the faster path to revenue and to the real usage data that eventually justifies architectural complexity.

What a Well-Structured Modular Monolith Looks Like

The modular monolith satisfies the primary objection to "just build a monolith" — that a poorly-structured monolith becomes an unmaintainable coupling nightmare. A modular monolith avoids this through strict architectural discipline:

/src
  /modules
    /orders          ← business domain boundary
      /api           ← HTTP layer, input validation
      /services      ← business logic
      /repositories  ← data access
      /events        ← domain events the module emits
    /inventory
      /api
      /services
      /repositories
      /events
    /billing
      ...
  /shared
    /infrastructure  ← database connection, queue, cache
    /events          ← event bus implementation
    /utils

The critical discipline: modules must not import from each other's internal layers. Modules communicate only through defined interfaces (service methods or events). This constraint, enforced through linting rules or architecture tests, prevents the coupling that makes monoliths hard to change.

When a module needs to grow to a separate service, the extraction is clean: the module's service interface becomes an HTTP API; the event bus calls become message queue publishes; the shared database tables are copied and synced during the migration period. The preparation investment has been made; the extraction is an operational decision, not an architectural rewrite.

Real Architecture Decisions for Nigerian Businesses

For a Nigerian B2B SaaS company at ₦100M–₦1B revenue with a five-to-twelve-person engineering team: start with a modular monolith.

Specifically:

Single Next.js or Node.js application with clearly bounded modules
PostgreSQL or D1 as the single data store with schema-level domain boundaries
Background jobs in the same codebase via a queue (BullMQ, Cloudflare Queues) — not separate services
Horizontal scaling via replicas behind a load balancer when traffic demands it (this addresses 95% of web application scaling requirements)

For a Nigerian fintech at ₦1B+ revenue with fifteen-plus engineers and demonstrably different resource profiles between payment processing, fraud detection, and customer-facing APIs: selective service extraction — the payment processing pipeline as a separate service (because its reliability, compliance, and scaling requirements genuinely differ), everything else in the modular monolith until the evidence supports further extraction.

The architecture decision is not about what kind of company you want to be — it is about what your current team, traffic, and business requirements actually need. Premature microservices impose a real tax on delivery velocity that small teams in the Nigerian market cannot afford.

API Architecture: End Integration Hell — Designing APIs that make integration painless
Multi-Tenancy Architecture for SaaS at Scale — Scaling your architecture for multiple customers
Database Choices for Nigerian Business Applications — Selecting the right database for your architecture