“a hybrid of microservices architecture style and is considered one of the most pragmatic architecture styles, mostly due to its architectural flexibility.” – “Fundamentals of Software Architecture” by Mark Richards & Neal Ford

Description

If done correctly, Service Based Architecture (SBA) can be incredibly flexible, yet simple to build and maintain.

I think of SBA’s as I would a three-layer CRUD app: there’s a frontend, a backend, and a persistence layer. Now instead of backend we should think service.

What’s a service?

In this context a service is typically a REST API server that performs business logic in its specific domain.

A service in this stack could also be something like a queue worker which wouldn’t require a REST API.

In practice, the service is whatever you decide you need.

Variants

SBA’s flexibility allows for variations from it’s traditional definition and can adapt to your applications needs.

Find that sharing the same database across all services creates too much coupling? Create a database for each service.

Find that you’d really prefer to use a messaging service and an event log? Go ahead!

But with this flexibility comes common pitfalls. Data can sometimes get stored too far from where it’s needed for processing. Services can become tightly coupled, creating an environment where the same work is spread across multiple services.

Diagram

Shared Database

Single DB

Isolated Database

Multiple DBs

Pros

  • Domain-partitioned architecture can have an overall positive effect on project
  • Incredibly flexible and resilient
  • Can change with business requirements
  • As a distributed system it can scale services independently
  • Stepping stone to microservices

Cons

  • Flexibility allows for lots of chance to cut corners
  • While this can resemble microservices, it does not come with the methodologies and opinionated design restrictions, leading to a false sense of scalability in distributed system
  • If untethered or unwatched, complexity and coupling between services can run rampant

When to Use

I’d recommend using SBA in some of the following scenarios:

  1. Small team, budget, or timeline
  2. Knowing very little of your final business requirements
    • Or you anticipate they may change rapidly
  3. Small teams that need some flexibility when designing, building, and shipping features
  4. Having a desire to separate technology by domain into reusable components