Free lesson · Microservices Interview

SOA vs Microservices vs Service-Based Architecture

Easy10 min readmicroservicessystem-designdistributed-systems

SOA vs Microservices vs Service-Based Architecture

Candidates frequently conflate microservices with any form of service decomposition. In interviews, this shows up as vague language - "I would use a service-oriented approach" - that signals the candidate has not thought precisely about which architectural style they mean and why.

This lesson maps the landscape. Three distinct architectural styles - SOA, microservices, and service-based architecture - share the idea of decomposing a system into services but differ in important ways that affect design decisions, team structure, and operational complexity. Understanding these differences lets you use precise vocabulary in interviews and choose the right style for the problem at hand.

Service-Oriented Architecture (SOA)

SOA emerged in the early 2000s as an enterprise architecture pattern. It was a response to the same problem microservices later addressed - large organisations needed to decompose their monolithic systems into reusable components - but it took a fundamentally different approach.

The Core Idea

SOA organises an enterprise's functionality into services - reusable business capabilities exposed through standardised interfaces. The key architectural element is the Enterprise Service Bus (ESB), a centralised middleware layer that handles routing, transformation, orchestration, and protocol mediation between services.

graph TD
    subgraph SOA["Service-Oriented Architecture"]
        C1["CRM\nService"] --> ESB["Enterprise\nService Bus"]
        C2["Billing\nService"] --> ESB
        C3["Inventory\nService"] --> ESB
        C4["Reporting\nService"] --> ESB
        ESB --> DB1["Enterprise\nDatabase"]
    end

This diagram shows a Service-Oriented Architecture where four services - CRM, Billing, Inventory, and Reporting - all communicate through a central Enterprise Service Bus. The ESB connects to a shared enterprise database. Communication is centralised through the bus rather than being point-to-point between services.

SOA Characteristics

Centralised governance. An architecture review board defines service contracts, communication protocols, data formats, and naming conventions. Teams do not make independent technology choices - they conform to enterprise standards.

Enterprise Service Bus. The ESB is the nervous system. It handles message routing, protocol translation (SOAP to REST, XML to JSON), message transformation, and business process orchestration. The ESB is powerful but it is also a single point of failure and a centralised bottleneck that one team must maintain.

Shared data layer. SOA services commonly share a database or a canonical data model. The enterprise data model is managed centrally, and services operate on it rather than owning their own data stores. This makes cross-service queries easy but creates the same coupling problems we discussed in the previous lessons - a schema change can ripple across services.

Coarse-grained services. SOA services tend to be large - a "Customer Management Service" that handles customer creation, authentication, profile management, preferences, and communication history. They are more like subsystems than the small, focused services in a microservices architecture.

SOAP and WS- protocols.* SOA was built in the era of SOAP, WSDL, WS-Security, WS-ReliableMessaging, and the broader WS-* specification family. These protocols are verbose, complex, and heavyweight compared to modern REST and gRPC - but they provided features (reliable messaging, transaction coordination, security) that were important for enterprise integration.

Where SOA Went Wrong

SOA was not a bad idea. The problem was implementation complexity. The ESB became a development bottleneck - every new integration had to go through the ESB team. The WS-* protocols were so complex that implementing a simple service interaction required extensive XML schema design, WSDL definition, and SOAP envelope construction. The centralised governance slowed teams down rather than enabling them.

The ESB also tended to accumulate business logic over time. What started as a routing and transformation layer gradually became the place where orchestration flows, validation rules, and data transformations lived. This created a situation where the "services" were thin shells and the ESB was a distributed monolith in disguise - all the important logic centralised in one component that one team maintained and everyone depended on.

Many organisations spent millions of dollars on ESB products (IBM WebSphere, Oracle Service Bus, TIBCO) and ESB integration teams, only to find that the ESB itself became the bottleneck they were trying to eliminate. The irony of SOA is that it was designed to reduce coupling between systems, but the centralised infrastructure it relied on created a new form of coupling - every service was coupled to the ESB.

Warning: The ESB anti-pattern is the core lesson from SOA. When business logic migrates into the communication infrastructure, you lose the benefits of decomposition. This same mistake can happen in microservices with API gateways or orchestration services that accumulate too much logic. The principle is the same: keep the communication layer dumb and the services smart.

Microservices - The Correction

Microservices emerged in the early 2010s as a reaction to the problems SOA created. The core philosophical shift was from centralised to decentralised - decentralised governance, decentralised data, decentralised communication, decentralised technology choice.

We defined microservices properties in the previous lesson. Here is how they map as a direct response to SOA's problems:

The phrase that captures the microservices philosophy is "smart endpoints, dumb pipes." The services themselves contain the business logic. The communication infrastructure - HTTP, message brokers, event streams - is a dumb transport layer that moves data without interpreting it. This is the opposite of SOA, where the ESB was the smart layer and services were often thin.

What Microservices Got Right

Decentralised data ownership eliminated the shared-database coupling that made SOA services difficult to change independently.

Lightweight communication (REST, gRPC, async messaging) reduced the integration complexity from weeks to hours.

Small team ownership aligned incentives - the team that writes the code also operates it in production.

Independent deployability freed teams from coordinated release cycles.

What Microservices Made Harder

Cross-service data queries that were trivial with a shared database now require API calls, data replication, or CQRS patterns.

Distributed transactions that the ESB could coordinate now require sagas with compensation logic.

Operational complexity increased because N services means N deployment pipelines, N monitoring setups, and N potential failure points.

Service discovery and routing that the ESB handled centrally now needs to be solved with service registries, API gateways, or service meshes.

These are not design flaws - they are the cost of decentralisation. The microservices community decided that cost was worth paying to eliminate the bottlenecks that centralised governance created. Whether that trade is right for your system depends on your scale, your team, and your specific requirements.

Service-Based Architecture - The Middle Ground

Service-based architecture is the architectural style that most teams actually end up building, even when they think they are building microservices. It sits between a monolith and microservices in terms of granularity, data ownership, and operational complexity.

The Core Idea

A service-based architecture decomposes a system into a moderate number of coarse-grained services (typically 4–12), each of which may share a database or use a small number of shared databases. Services are larger than microservices - closer to SOA in granularity - but they use lightweight communication (REST, messaging) rather than an ESB.

graph TD
    subgraph SBA["Service-Based Architecture"]
        S1["Order\nDomain Service"] --> DB1["Orders DB"]
        S2["Customer\nDomain Service"] --> DB2["Customer DB"]
        S3["Fulfillment\nDomain Service"] --> DB1
        S3 --> DB2
        UI["UI Layer"] --> S1
        UI --> S2
        UI --> S3
    end

This diagram shows a service-based architecture with three domain services - Order, Customer, and Fulfillment - and two databases. The Order and Fulfillment services share the Orders database, and the Fulfillment and Customer services share the Customer database. This illustrates the pragmatic database sharing that distinguishes service-based architecture from strict microservices.

Service-Based Architecture Characteristics

Larger services. Instead of a separate service for orders, invoices, payments, and refunds, a service-based architecture might have a single "Financial Domain Service" that handles all of these. The service is bigger, but it is still independently deployable and maintained by one team.

Pragmatic database sharing. Services may share databases when the cost of separating them exceeds the benefit. Two services that frequently need to join data across their domains might share a database with separate schemas - not ideal from a microservices purist perspective, but pragmatically effective.

Fewer services, lower operational overhead. A service-based architecture with 6 services has dramatically lower operational complexity than a microservices architecture with 60 services. Fewer deployment pipelines, fewer network hops, fewer things to monitor.

Easier transactions. Because services are larger and may share databases, ACID transactions across related concepts are still possible within a service. Only inter-service interactions require distributed coordination.

When Service-Based Architecture Is the Right Choice

Service-based architecture is often the right choice for organisations that:

• Are too large for a monolith (30+ engineers) but not large enough to justify full microservices (under 100 engineers)
• Have moderate complexity that can be decomposed into 4–12 domain areas rather than requiring dozens of fine-grained services
• Need independent deployability for major domain areas but do not need it at the granularity of individual bounded contexts
• Want to avoid the operational overhead of a full microservices infrastructure (service mesh, extensive distributed tracing, dozens of CI/CD pipelines)

The important point is that service-based architecture is not a compromise or a half-measure. It is a legitimate architectural style with its own strengths. Many successful systems run on it permanently, not as a way station toward microservices.

Service-Based Architecture in Practice

To make this concrete, consider a mid-size e-commerce company with 60 engineers. A full microservices decomposition might produce 25-30 services - order service, inventory service, payment service, pricing service, promotion service, notification service, user service, search service, recommendation service, review service, shipping service, warehouse service, and so on. That is 25-30 deployment pipelines, 25-30 sets of health checks, and a substantial investment in distributed tracing and service mesh infrastructure.

A service-based decomposition of the same system might produce six domain services:

1. Commerce Domain Service - orders, cart, checkout, pricing, promotions
2. Catalog Domain Service - products, categories, search, reviews
3. Customer Domain Service - user accounts, authentication, profiles, preferences
4. Fulfillment Domain Service - inventory, shipping, warehouse management
5. Financial Domain Service - payments, invoices, refunds, accounting
6. Engagement Domain Service - notifications, recommendations, marketing campaigns

Each service is larger than a typical microservice, but each is still independently deployable, maintained by a single team of 8-10 engineers, and has clear domain boundaries. The operational overhead is dramatically lower. Cross-domain data needs are handled through APIs between the six services. Within-domain data needs are handled through internal function calls and shared database schemas.

This is a pragmatic architecture that works well for the company's actual scale and team size. Moving to full microservices later, if the company grows to 300 engineers, is possible by decomposing individual domain services - but there is no reason to pay the microservices tax at 60 engineers when service-based architecture provides the team independence needed.

The Spectrum

These three styles sit on a spectrum of granularity and decentralisation. Understanding the spectrum helps you make precise recommendations in interviews rather than treating "microservices" as a binary choice.

graph LR
    subgraph Spectrum["Architectural Spectrum"]
        direction LR
        Mon["Monolith\n1 deployment unit\n1 database\n1 team"]
        SBA["Service-Based\n4-12 services\nShared or separate DBs\nSmall number of teams"]
        Micro["Microservices\nMany small services\nDB per service\nTeam per service"]
        
        Mon --> SBA
        SBA --> Micro
    end
    
    More_Simple["Simpler operations\nStronger consistency\nTighter coupling"] -.-> Mon
    Micro -.-> More_Complex["Complex operations\nEventual consistency\nLoose coupling"]

This diagram shows the architectural spectrum from monolith on the left to microservices on the right, with service-based architecture in the middle. Moving left gives simpler operations, stronger consistency, and tighter coupling. Moving right gives more complex operations, eventual consistency, and looser coupling. Monoliths have one deployment unit and one database. Service-based has 4 to 12 services with shared or separate databases. Microservices have many small services with a database per service.

The spectrum is useful because it reframes the interview question. Instead of "should I use microservices - yes or no?" the question becomes "where on this spectrum should this system sit, and why?" That framing naturally leads to more nuanced answers.

Interview: Using the spectrum in an interview: "For this system, I think we are looking at something between service-based and microservices. The core domains - order management, payment, delivery - should be separate microservices because they have genuinely different scaling, consistency, and team ownership requirements. But within the order domain, I would keep order creation, order tracking, and order history in a single service rather than splitting them into three nano-services that constantly call each other."

This answer demonstrates that you think in terms of a spectrum rather than a binary choice, and that you can reason about where on the spectrum each part of the system should sit.

Common Interview Mistakes

Three mistakes I see regularly when candidates discuss these architectural styles:

Mistake 1: Treating SOA and microservices as synonyms. They are related but different. If an interviewer asks "how is this different from SOA?" and you cannot answer, it signals shallow understanding. The key distinction is governance model: centralised (SOA) versus decentralised (microservices).

Mistake 2: Ignoring service-based architecture entirely. Many candidates think the only options are monolith and microservices. Proposing a service-based architecture - "I would decompose this into five domain services rather than twenty fine-grained microservices" - can be the strongest answer when the system's complexity and team size fit that granularity.

Mistake 3: Choosing microservices by default. Candidates who reflexively propose microservices for every problem, regardless of scale, signal that they are applying a pattern without evaluating its fit. The first lesson in this course established that microservices are a trade, not an upgrade. This lesson adds that the trade is not binary - you can take it partially, at the granularity that matches your needs.

What Comes Next

The next lesson tackles the organisational dimension that underlies all of these architectural styles - Conway's Law and the relationship between team structure and system architecture. Understanding Conway's Law is what separates a purely technical architecture decision from a sociotechnical one, which is how senior engineers actually think about system design.

Back to Microservices Interview