Traditional client-server communication is based on request-response paradigm

The purpose of microservice architecture is durability and scalability. Durability means a service continues to serve requests during failures or peak traffic

The key feature of API Gateways is the access to all system requests, services they target, and outgoing responses

As we discussed earlier, microservices tend to accumulate a lot of repeated concerns unrelated to their responsibilities

Let’s return to our migration from a monolith. Imagine we’ve successfully split it into dozens of microservices

While the key idea behind micro-frontends is the same as for microservices — independent development and deployment — micro-frontend architecture presents very different problems

Historically, user-facing applications were rendered on the server — the same place where all logic resides

As we learned in the previous episode, not every decision benefits from decentralization

Microservice team autonomy means freedom to choose technologies: languages, frameworks, databases, infrastructure

“Don’t Repeat Yourself” principle sits at the core of software engineering. We usually structure our code to have as few to changes as possible when requirements shift

As discussed in the previous post, the proper approach of data ownership in microservice architecture is for each service to have its own database hidden behind a network API

The core idea of microservice architecture is decoupling: separate teams, codebases, lifecycles. Yet often it is still tempting to share a database between multiple services

When an architectural change this big is agreed upon, it is natural to perform migration of the whole monolith at once

A classic question when designing microservices: what defines a good boundary?

Imaging we have a patient data management system for hospital intensive care units (ICUs), built as a monolith

The core of microservice approach contains two ideas

When a project grows successfully, with time amount of code grows, and more devs are hired. This often leads to

Microservices have many benefits — but they are not a default choice for greenfield projects

Let’s revise what were the responsibilities of Enterprise Service Buses

The late 2000s to early 2010s marked the emergence of cloud computing. AWS and Google Cloud made on-demand compute available at scale