Service-Based Architecture

This will be easy to confuse with microservices architecture, but I'll try to help out! "Fundamentals of Software Architecture" is the book I'm using as a reference, I like to go back to the basics and review them at different points in time in my career. So here we go.

While this architecture is not overly complex, what made it click for me, was to think about each service as domain-based rather than individual functionality. I was happy to find out that Mark Richards and Neal Ford introduced it in these terms as well. Commonly speaking, a service-based architecture includes a user interface, a few domain-based components or services, and a shared DB.

The flexibility of this approach is that this topology can vary based on needs. You can have multiple instances of a service, multiple user interface components, and even multiple databases. I believe the main selling point though is to keep things as coherent and simple as possible. This can be achieved by staying away from breaking out things unless you absolutely need to. The moment you start to cross your wires (e.g. you split the database in two but now the data in one is needed from a different service) you defeat the purpose of this architectural approach.

The way it differentiates itself from a microservices approach is in the granularity of its services. While microservices see orchestration happening at the service level, we instead experience it at a class level. Simply put with an example, if you think about any subscription-based service, when a user initiates one, we might have the SubscriptionService handle it from top to bottom including payments. In a microservices world, the payment portion might be instead handled by a dedicated service. This introduces some trade-offs as now any change to payments might involve revisiting tests for the whole SubscriptionService macroservice.

Thoughts

Service-based architecture provides a pragmatic approach without making too many sacrifices. It is ideal for its simplicity, especially if the main paint points of scalability are unknown. Rather than introducing complexity first, by breaking down your application into fine-grained services, you wait for when you start feeling some "pains". From the example made before, you have the advantage of having changes to subscriptions contained in one coarse service rather than several smaller ones. This also means applying changes is simpler and easier to deploy. Speaking from experience I witnessed the "complexity first" approach where an application with 0 users was designed with microservices and a globally distributed database. This added so many complexities and headaches way ahead of time. Everything looked good "on paper" until the development was ongoing. Unfortunately, it didn't see the light of day but I strongly believe that a monolith or a service-based architecture would have got the team to production A LOT faster.