Manu's Vault

Service Based Architecture Style

3 min readStatus:Seedling

Core Idea

Service-Based Architecture is a distributed macro-layered architecture that organizes coarse-grained services (typically 4-12) around business domains, each with its own database. It balances the simplicity of monolithic architecture with some benefits of distributed systems, offering a pragmatic middle ground.

Architecture Overview: Service-based architecture represents a practical distributed architecture style that breaks a system into separately deployed domain services while avoiding the extreme granularity and operational complexity of microservices:

  • Each service is a coarse-grained domain partition
  • Typically represents significant business capabilities like Order Management, Customer Management, or Inventory
  • Balances distribution benefits with operational simplicity

Topology Components:

  • User interface layer: Accesses multiple domain services
  • Domain services: Each owns its database (though database sharing is permitted, unlike microservices)
  • Independent deployment: Different teams work on different domains without stepping on each other’s toes
  • Coarse-grained services: Unlike microservices, each service typically contains multiple components and substantial business logic

Data Management Flexibility: A key characteristic is the style’s pragmatic approach to data:

  • Each service can have its own database
  • Services may share databases when practical concerns outweigh isolation benefits
    • Joins across data
    • Transactions spanning multiple entities
    • Data consistency requirements
  • This pragmatism distinguishes service-based architecture from more dogmatic distributed styles

Communication Patterns:

  • Uses API-based communication between services, often through REST or messaging
  • Coarse-grained services mean inter-service communication is less chatty than in microservices architectures
  • Reduces network latency concerns
  • Services can be developed in different technology stacks, though many organizations choose consistency for operational simplicity

Strengths and Use Cases: Service-based architecture excels at domain partitioning and moderate scalability:

  • Well-suited for systems needing more modularity and independent deployability than a monolith provides
  • Avoids the operational complexity of microservices
  • Common use cases:
    • Mid-sized business applications
    • Systems transitioning from monoliths
    • Organizations without extensive DevOps infrastructure

Trade-offs:

  • Gains vs monoliths: Independent deployability, fault isolation, and scalability
  • Accepts: Network latency, distributed debugging complexity, and data consistency challenges
  • Sacrifices vs microservices: Extreme scalability and independent scaling
  • Gains vs microservices: Simpler operations and reduced architectural overhead

Why This Matters

Service-based architecture is often the “sweet spot” for many organizations—distributed enough to gain modularity and scalability, but pragmatic enough to avoid microservices’ operational burden. It’s particularly valuable for teams transitioning from monolithic architectures who need distribution benefits without a complete organizational transformation. Understanding this style prevents both over-engineering (choosing microservices when unnecessary) and under-engineering (staying monolithic when domain separation would provide value).

Sources

Note

This content was drafted with assistance from AI tools for research, organization, and initial content generation. All final content has been reviewed, fact-checked, and edited by the author to ensure accuracy and alignment with the author’s intentions and perspective.

Graph View

Backlinks