# Layers vs Silos, a tale of 2 microservice architectures

DevFeed: [Layers vs Silos, a tale of 2 microservice architectures](<https://devfeed.tech/articles/layers-vs-silos-a-tale-of-2-microservice-architectures-20097.md>)

Original publisher: [Read original article](<https://medium.com/jobteaser-dev-team/layers-vs-silos-a-tale-of-2-microservice-architectures-50c21016e9b1?source=rss----bd77d16a0035---4>)

Author: Emmanuel Joubaud

Published: 2023-04-07T10:01:02Z

Content type: article

Language: en

Sources: [JobTeaser](<https://devfeed.tech/sources/jobteaser.md>)

Topics: [Microservices](<https://devfeed.tech/topics/microservices.md>), [Architecture & Design](<https://devfeed.tech/topics/architecture-design.md>), [API](<https://devfeed.tech/topics/api.md>), [event driven](<https://devfeed.tech/topics/event-driven.md>), [Replication](<https://devfeed.tech/topics/replication.md>), [Databases](<https://devfeed.tech/topics/databases.md>)

Tags: [api](<https://devfeed.tech/tags/api.md>), [architecture](<https://devfeed.tech/tags/architecture.md>), [database](<https://devfeed.tech/tags/database.md>), [event-driven](<https://devfeed.tech/tags/event-driven.md>), [go](<https://devfeed.tech/tags/go.md>), [microservices](<https://devfeed.tech/tags/microservices.md>), [replication](<https://devfeed.tech/tags/replication.md>), [ruby](<https://devfeed.tech/tags/ruby.md>), [software-architecture](<https://devfeed.tech/tags/software-architecture.md>), [software-engineering](<https://devfeed.tech/tags/software-engineering.md>)

## AI overview

This article compares two extreme communication patterns for microservices: synchronous API calls, which tend to create layered dependencies, and asynchronous event-driven communication or data replication, which tends to create more independent silos. It presents these patterns as a spectrum and discusses trade-offs in business and composition layers.

## Source excerpt

When it comes to the communication between microservices, there are 2 possible extremes: All-sync: whenever a service needs data from another service, it fetches it via a synchronous API call (REST, gRPC, GraphQL). Service calls service calls service... which tends to evolve into layers of APIs, where each layer has dependencies on the next. All-async: no sync calls between services, all communication is event-driven or in the form of data replication. This tends to form silos: independent services that are fed all the data they need by an async mechanism and can function independently of any other service's availability. Of course real-world systems rarely fit either of these 2 extremes perfectly. But whether you plan for it or not, you'll probably end up with a dominant mode or, worse, a random mix. Imagining a spectrum between these 2 extremes can offer a helpful mental model to design a more deliberate architecture, where you control the set of circumstances under which you tend towards one or the other, and the associated trade-offs. LayersAn exemple of layers architecture, for a Career Service Management SystemBusiness layer So you've started building a bunch of business services for your microservice application. They implement business logic and store data. For isolation, you chose to go database-per-service: each service stores a bunch of business objects for which it is the Source of Truth. If you opt for sync-only communications between your services, that means any time one service needs to read another's data, it has to make a synchronous API request to the Source of Truth service, introducing a dependency between them. And if you map those dependencies on a graph, you'll likely notice that software systems tend to contain a few business objects that are depended on way more than others. They're the core of the dependency graph. Often they're your users, your referential data (categories), the items of your e-commerce site, etc. So even within your "busin