Blog — George Mishurovsky: posts tagged series

Decoupling Responses from Requests: Event-Driven Approach | Microservice Architecture — Ep. 26

Sat, 21 Mar 2026 12:38:00 +0200

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

send a request
show loading state and wait
get the response
update client state

However, microservice architecture does not go along well with it because of two things:

multiple network hops (high cumulative latency)
request-response propagation through service chains
So many requests turn into small distributed workflows.

Consider a simple subscription-based video platform. One frontend and three services: Subscriptions, Payments, Recommendations.

The typical “subscribe” workflow may look like this:

Client calls Subscriptions.
Subscriptions calls Payments.
Payment succeeds.
Recommendations builds a personalized movie list.
Client fetches recommendations.

Where does this orchestration live?

In the frontend? → tight coupling to backend internals
In a BFF? → centralized coordination and sequential bottlenecks
Both approaches are fragile due to excessive coupling. And if each service talks to each in request-response paradigm, it becomes a tough task under load, having to support hundreds and thousands of open connections.

An alternative is to decouple responses from requests using events. Instead of calling each other and waiting for long responses, services communicate through a message broker:

Subscriptions emits ‘UserSubscribed’
Payments consumes it and processes payment
Payments emits ‘PaymentCompleted’
Subscriptions and Recommendations react independently
Recommendations emits ‘RecommendationsReady’
Some Notifications service may send an email or a live update to the frontend client

With event-driven architecture we achieve three things:

services no longer keep open connections, waiting only for confirmation from message broker
if some service breaks, requests are not lost, but can be picked up from the message broker by another service instance
there is no node concerned with process coordination — coordination complexity is moved to communication space
the system becomes asynchronous: frontend clients receive immediate feedback and unlock other activities while complex workflows are processed in background

The tradeoff — we lose immediate consistency. The benefit — we gain scalability, resilience, and simple service boundaries. This shift, from waiting for results to reacting to events, is one of the key mindset changes in distributed systems.

Auto-Scaling Groups and Load Balancers | Microservice Architecture — Ep. 25

Fri, 06 Mar 2026 10:15:00 +0200

The purpose of microservice architecture is durability and scalability. Durability means a service continues to serve requests during failures or peak traffic. Scalability means achieving durability with the least resources possible, making the service cost-efficient.

Most modern microservices typically run on small virtual machines with limited vCPU and RAM. These instances are cheap, but still powerful enough to handle thousands of requests per minute.

However, running a single instance of a service is never enough, as hardware failures are rare but inevitable — even in the best data centers. To maintain durability, at least two instances of a service must run in different data centers (“availability zones” in AWS terminology).

Another issue is traffic spikes. When load increases, a single instance becomes incapable of handling all requests, so multiple instances become a necessity.

In practice, service load changes dynamically, e. g. low at night and ten times higher of that during business hours. For cost efficiency, services are usually placed in auto-scaling groups. A dedicated agent monitors metrics such as CPU usage or request rate and automatically adds or removes instances as load surpasses predefined thresholds. Scaling achieved through changes in a number of small instances is called horizontal scaling.

Horizontal scaling introduces another challenge: how do clients know which instance to talk to?

An API gateway routes requests to services, but it should not track which instances currently exist or which ones are healthy. That responsibility is delegated to load balancers — lightweight proxy services that:

track active service instances and their IP addresses
monitor instance health and availability
distribute load evenly across instances

As load balancers expose a stable endpoint (often a static IP or DNS name), API gateways can simply route requests to them — offloading instance discovery and traffic distribution to the combined work of load balancers and auto-scaling groups.

Why API Gateways Became a Thing (Part 2) | Microservice Architecture — Ep. 24

Mon, 02 Mar 2026 11:00:00 +0200

The key feature of API Gateways is the access to all system requests, services they target, and outgoing responses. This position enables capabilities that go beyond simple routing.

Let’s peek into these capabilities.

API Versioning
If multiple API versions exist, the Gateway can forward requests targeting specific API versions to the matching service implementations, centralizing backward compatibility.

Canary Deployments
The Gateway can route portions of traffic to new service instances running updated code. As it has access to request and auth data, it can do so based on routes, headers, regions, or tenant attributes.

Basic validation
The Gateway may check for oversized payloads and validate basic schema constraints before traffic reaches services, reducing unnecessary system load.

Request / Response transformation
The Gateway may enrich requests, e. g. inject tenant data or correlation IDs. In the same manner it can reshape responses, e. g. by hiding internal fields from response payloads.

Data aggregation
In simple cases, the Gateway can split a request across multiple services and combine responses before returning them, reducing the need for separate aggregation services.

Caching
The Gateway can cache common GET requests, improving latency for high-traffic endpoints and protecting downstream services from excessive load.

The API Gateway is not just a router and observer — it is a policy enforcement and traffic management layer.

Why API Gateways Became a Thing (Part 1) | Microservice Architecture — Ep. 23

Sat, 28 Feb 2026 11:00:00 +0200

As we discussed earlier, microservices tend to accumulate a lot of repeated concerns unrelated to their responsibilities. If something repeats across services, we should try to move it into a separate service that clients hit first before talking to downstream services — some Gateway.

What can we hand off to the Gateway?

Routing
Public-facing services have IPs which are prone to change. The Gateway provides stable routes, discovers service IPs and forwards requests to the right targets.

Protocol translation
Services do not need to support any protocol. Teams pick the most appropriate one, and the Gateway translates requests and responses as needed.

Authentication and tiered access
Domain services should not parse tokens or know about subscription tiers. The Gateway validates credentials, checks access levels, and can short-circuit unauthorized requests before they reach downstream services.

TLS termination
If traffic enters through a single point, TLS can be terminated at the Gateway. Internal services may communicate over simpler internal channels (though in high-security environments, end-to-end encryption may still be required).

Request logging and monitoring
As the Gateway handles all requests, it can centrally log user activity and provide metrics.

Request throttling
The Gateway can track whether a client puts excessive load on the system and stop propagation of frequent requests. And as it sees authentication context and system-wide traffic patterns, it can enforce global rate-limiting strategies — individual services cannot do that effectively.

In short, the Gateway provides a stable application programming interface to an unstable internal world — it is the API Gateway. It hides topology, enforces global policies, and lets domain services focus on business logic. That is why it became a foundational pattern in microservice architecture.

Cross-Cutting Concerns in Microservices | Microservice Architecture — Ep. 22

Thu, 19 Feb 2026 12:11:37 +0200

Let’s return to our migration from a monolith. Imagine we’ve successfully split it into dozens of microservices. Some services are internal, some face clients.

The company grows, the number of clients increases — along with their demands:

new devices
new protocols
new response formats
new pricing tiers
Multiple services, combined with lots of clients lead to complex inter-service relations.

If we take a naive approach and extract domain slices into services along with everything required to provide proper access — every team will be solving the same set of problems.

Each service now has to:

support multiple communication protocols
handle authentication
evaluate tenant tiers
manage throttling and load balancing
collect logs, metrics, and tracing data

There is one more problem — data aggregation. Many endpoints need data from multiple services. To reduce latency, we introduce caching, but:

some queries are hot, others are rarely used
some queries require near real-time freshness
different clients may need different response shapes
different clients may want to combine data from different domains

Aggregation services risk becoming bloated and complex, with clusters of similar endpoints coupled to specific client needs, and excessive duplication of both code and cached data.

How can we address these problems?

Micro-Frontends and the Illusion of Isolation | Microservice Architecture — Ep. 21

Wed, 18 Feb 2026 11:00:00 +0200

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

No real isolation.
Backend microservices run in separate processes — often on separate machines. Micro-frontends share the same browser tab: the same DOM, CSS namespace, event system, storage, and main thread.

Limited deployment independence.
Backends integrate over the network — but micro-frontends integrate in memory. They depend on a shell application, shared routing and design systems: braking changes in those layers affect everyone.

Shared data is unavoidable.
A lot of frontend state is cross-cutting: feature flags, session, auth, cart contents. We can modularize code, but cannot pretend data ownership is cleanly separated.

Shared and constrained hardware.
On the backend, a slow service does not block CPU for others and can be easily scaled. In the browser, components compete for the same main thread, often on low-end mobile devices. Performance budgets are a cross-team concern.

Integration problems are very prominent.
Backend failures degrade responses. With proper loading and fallback states in UI, users may not even notice. Frontend failures degrade user experience: broken layout, flicker, inconsistent interactions — all seen immediately.

Splitting responsibility without breaking UX is the real challenge of micro-frontends.

What are Micro-Frontends? | Microservice Architecture — Ep. 20

Wed, 11 Feb 2026 16:32:25 +0200

Historically, user-facing applications were rendered on the server — the same place where all logic resides. The backend processed requests and generated HTML dynamically.

Around 2010, single page applications (SPA) emerged. HTML started being generating in the browser using data from backend, which enabled complex state management and rich UI interactions.

Today, we see a partial return to server-side rendering (SSR) for performance and SEO reasons. Still, state orchestration and smooth UX remain complex enough to require dedicated frontend expertise.

Just like backend systems, frontend codebases often start as monoliths. And just like in the backend world, once a frontend team grows beyond ~5 engineers, coordination becomes harder, release cycles slow down, and ownership becomes blurry, calling for split teams — the micro-frontend approach.

Usually this is achieved by having a shell application that provides layout, routing, and shared infrastructure. Independent frontend teams work on separate pages or feature slices, that are composed at runtime.

Core principles of micro-frontends:

Isolation
Unlike backend microservices, code from different teams ends up in the same browser page — so teams have to namespace CSS classes, browser events, cookies and local storage items.

Resilience
A robust frontend prioritizes server-side rendering and progressive enhancement. Teams should rely on server-side rendering, using client-side JS to enhance UX.

Technology agnosticism
Teams should be able to choose their frontend stacks, which should not affect performance or user experience of the whole SPA.

Microservice thinking is not limited to backend systems. The idea of independent teams working on well-defined, isolated components applies to any system divisible by such components.

Team Autonomy That Actually Scales | Microservice Architecture — Ep. 19

Mon, 09 Feb 2026 11:19:14 +0200

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

When microservices use technologies different from the original monolith, the organization pays:

a one-time cost to set up each service
a recurring cost to operate and support it

The cost of building actual features, however, stays roughly the same regardless of language or paradigm.

So autonomy should be tiered — unify decisions that reduce operational and coordination overhead!

1. Strict tier
Single standards to avoid repeated work across teams:

infrastructure — cloud provider, core services, machine types
API standards — protocol, versioning and deprecation rules (might differ by service class)
monitoring and alerting — shared logging, metrics, and alerting conventions
security policies — access control, secret rotation, PII handling

2. Relaxed tier
A small set of options (2–5 choices) to balance flexibility and cognitive load:

programming languages and frameworks
messaging technologies
database technologies

3. Guardrail tier
Default “golden paths” teams follow unless they consciously opt out:

recommended tech stacks
starters and templates
base CI/CD pipelines

4. Free tier
Fully team-owned decisions where autonomy improves effectiveness without added recurring costs:

internal quality practices
release process
release schedule

Tiered autonomy reduces infrastructure and support costs, while giving teams enough freedom to organize their work effectively.

Why You Don’t Want Complete Team Autonomy | Microservice Architecture — Ep. 18

Fri, 06 Feb 2026 11:00:00 +0200

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

Imagine splitting a large monolith into 10-20 microservices. Each team picks a stack different from the original system — and different from each other.

This leads to:

new folder structures
new code style conventions
new linting rules
new test harnesses
new database schemas
new CI/CD pipelines
new infrastructure definitions
new monitoring and alerting setups

And this can turn very problematic:

Most of these decisions require thorough analysis with long discussions — even within a single team.
Engineers face a steep learning curve as the whole tech stack differs from the one they are used to.
API boundaries become harder to reason about when teams mix REST, GraphQL, RPC, and custom protocols.
Infrastructure complexity explodes — the teams might start spending more time on configuration than on writing new features!

Microservices aim to enable independent teams and faster delivery — but not every decision benefits from decentralization.

What do you think might be a possible solution here? Share your thoughts in the comments!

I’m writing a full series on microservice architecture — from base definitions to hands-on topics like testing, deployment, and observability.
Follow or connect if you want to continue the series, or read them on my blog: https://mishurovsky.com/blog/tags/microservices-event-driven-architecture/

DRY vs Microservices: When Reuse Becomes a Liability | Microservice Architecture — Ep. 17

Wed, 04 Feb 2026 11:21:33 +0200

“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.

This approach is right inside any single microservice — use it! But it gets trickier when DRY is applied across microservices. Not every duplicated piece of logic should be extracted into a shared library.

Remember, the goal of microservice architecture is independent deployment. Shared libraries work against that goal and introduce coupling:

Updating a library forces coordinated releases across multiple services (who owns the library and coordination then, by the way?).
A bug in the library makes all dependent services vulnerable.
Frequent library updates open a potential for version conflicts and dependency hell.

So what if logic really needs to be shared?

If it is cross-service communication logic, sharing code can be a good tradeoff. Libraries or code generation to keep contracts in sync (schemas, clients, message definitions) usually increase development speed rather than hinder it.

If it is business logic, this might indicate a boundary problem. Combine microservices into a single, more cohesive one — or extract that logic into a dedicated service.

If introducing a new service is undesirable, the sidecar pattern is a possible solution. Move shared logic into a separate process running co-host with each service instance. This way service and sidecar lifecycles get separated, avoiding tight compile-time dependencies.

In microservices, duplication is often cheaper than coordination.

Problems of the “One Database per Microservice” Approach | Microservice Architecture — Ep. 16

Mon, 02 Feb 2026 12:17:02 +0200

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.

While this approach solves independent service development and deployment, it introduces strong downsides:

Accessing foreign data now requires a network call, typically adding 100 – 200 ms of latency.
Cross-service joins become inefficient: data must be fetched from multiple services, normalized, and only then combined.
Cross-service transactions get much more complicated — some services may use storage technologies that don’t support transactions at all!

How to cope with these problems?

Cache foreign data locally to reduce network calls. This improve latency, but introduces tough questions: what to cache and when to invalidate.
For complex joins, create a dedicated microservice that gathers data on schedule and stores join results in its own database (a benefit here is that it can keep and provide results of previous computations).
For cross-service transactions, use sagas. Each service defines forward and compensating actions, coordinated either via orchestration (by a separate coordinator service) or choreography (event-driven coordination configured for each participating microservice).

These solutions are not simple. The “one database per service” principle trades local simplicity for system-level complexity — but it remains the most scalable and sustainable approach for microservice architectures.

One Microservice — One Database | Microservice Architecture — Ep. 15

Fri, 30 Jan 2026 11:00:00 +0200

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, especially when the system is relatively small. But it is a wrong decision.

Why shared databases break microservices:

Microservice A cannot write to tables owned by microservice B, as each microservice must own its data undivided.

Microservice A cannot read tables owned by microservice B, as any schema change, table / row permission update, or migration can silently break downstream services.

Microservice A cannot keep its data in a separate table of microservice B’s database. If the B changes DB technology or scaling strategy, the tables of A have to be moved elsewhere, but by who owns the migration? It is especially complex issue once there are more than two services involved.

With direct DB connections, the load on IO from some fast growing service might become so intensive it would degrade operation of unrelated services.

This is why each microservice needs its own database. All access to that data must go through the service’s API or events, and never through direct database connections.

How to Migrate from a Monolith to Microservices (Without Regretting It) | Microservice Architecture — Ep. 14

Mon, 26 Jan 2026 14:59:00 +0200

When an architectural change this big is agreed upon, it is natural to perform migration of the whole monolith at once. Freeze all current development, develop a plan, split tasks and start. But beware!

If the decision to migrate is made, it is likely we already have a large codebase and an excessively large team that has lost coordination and velocity. The business will not accept months without new features, either.

The right way is to go incremental. Create a small team of experienced engineers, isolate a narrow component for migration, and set no hard deadlines. You will uncover unexpected issues early — but with limited scope, the cost of mistakes stays low and progress is still clearly visible.

How to execute the migration?

Define API of the component to be extracted.
Ensure its thorough automated test coverage with a 100% pass rate.
Isolate the component by removing dependencies on the monolith.
Extract into a microservice and ensure all tests passing.
Put the microservice behind a facade (e. g., an API gateway).
Route part of production traffic to it.
Monitor the service under the real load and fix issues.
Remove the extracted component from the monolith.
This approach is commonly known as the Strangler Fig Pattern.

Microservices migrations fail most often not because of technology — but because the change must be both technical and organizational.

Where to Split? | Microservice Architecture — Ep. 13

Fri, 23 Jan 2026 11:00:00 +0200

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

One approach is to split business capabilities. For an online store they can be:

Product Catalog
Search
Reviews
Cart
Billing
Shipping

Capability-based splitting usually leads to very stable services, as business needs evolve slowly and rarely require large-scale changes.

Another approach is to split by technical domains:

Core — unique functionality of this particular business (e. g. Product Catalog)
Supporting — industry-common core helpers (e. g. Cart, Billing, Shipping)
Generic — non-unique non-specific functionality (e. g. Auth, Search, Payment, Image Processing)

This model is more intuitive for engineers. It also makes it easier to decompose large domains into smaller services when scale or ownership demands it.

Both approaches focus on cohesion and loose coupling and achieve quite stable microservice boundaries under changing requirements.

Principles Behind Good Microservice Boundaries | Microservice Architecture — Ep. 12

Mon, 19 Jan 2026 11:00:00 +0200

Single Responsibility. Consumers of a service need to clearly understand its purpose.
High Cohesion and Exhaustiveness. All related functionality has to end up in the same service.
Low Coupling. Services should minimize dependencies on others — even if that means duplicating supporting code. Big codebases for microservices are OK as long as the services are cohesive and centered around a single business capability.

Imaging we have a patient data management system for hospital intensive care units (ICUs), built as a monolith. It manages patient information, prescriptions, treatment history, vital parameters, and provides a dashboard with current state and therapy.

❌ Wrong decomposition:

dashboard
care plan
monitoring

Why? Consider we add a new drug into the system. All services must change:

care plan — to prescribe it
monitoring — to display past treatments with the new drug
dashboard — to show current therapy

✅ Better approach:

drugs
vital parameters
timeline (treatment plans, current state, history)

Why? Available drugs and vital parameters change in one place, while evolution of timeline does not affect other services. Each service owns a stable business concept, not a UI page.

Good microservice boundaries reduce change coordination, not just code size.

Benefits and Challenges of Microservice Architecture | Microservice Architecture — Ep. 11

Fri, 16 Jan 2026 11:00:00 +0200

The core of microservice approach contains two ideas:

narrow business domains
small and independent teams (2-pizza team size)

So, splitting monoliths into microservices immediately brings benefits:

smaller codebases — easier to comprehend, faster to change
higher cohesion — easier to comprehend, more reasonable to scale when needed
smaller build sizes — cheaper infrastructure and better horizontal scaling

These benefits are balanced by fundamental trade-offs:

the system becomes distributed — network delays and partitions become ordinary and must be designed for
the system becomes asynchronous — integration and end-to-end testing becomes significantly harder
events are now processed by service chains — bugs become harder to trace, reproduce, and reason about
wrong service boundaries are expensive — errors here lead to numerous inter-service dependencies, spawning a “distributed monolith”, combining cons of both approaches while bringing few benefits

Microservices shift complexity from code size to communication structure, forcing boundaries between business logic and supporting infrastructure.

Problems of Monoliths in Growing Projects | Microservice Architecture — Ep. 10

Wed, 14 Jan 2026 11:00:00 +0200

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

a bloated codebase — harder for new engineers to understand, slower to change
tight coupling between many modules — releases require more coordination and happen less frequently
growing coordination overhead — N team members can form up to N² communication paths
legacy accumulation — dependencies receive updates, but codebase upgrades are postponed due to fear of breaking changes
longer build times
increasing hardware requirements for all environments

This is a time when teams start thinking about splitting the system into smaller, independently evolving parts.

Would you name the approach? :)

It is Right to Start with a Monolith | Microservice Architecture — Ep. 9

Mon, 12 Jan 2026 17:00:00 +0200

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

Monoliths have strong advantages that service-oriented approaches cannot offer:

the whole app is deployed as a single unit: if it compiles, cross-module integration is likely correct
development and refactoring are simpler: the compiler helps to track if changes are complete
cross-module calls are synchronous or close to synchronous, taking less than 1-10 milliseconds
testing is easier, with clear targets of integration and e2e tests
debugging is simpler: spin up the app locally, set breakpoints, attach a profiler — and you have the whole system for inspection

When monoliths are OK:

small projects
small teams
unclear domain
unclear scaling requirements

...basically, in most new projects.

Decomposition of ESBs into Cloud Services | Microservice Architecture — Ep. 8

Fri, 09 Jan 2026 17:00:00 +0200

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

service discovery and communication
request routing
protocol mediation
authN and authZ
rate limiting
logging and monitoring
workflow orchestration

These capabilities are generic. Any sufficiently complex system needs them — but they don’t need to live inside a single, centralized component.

In cloud-native systems, ESBs were effectively decomposed into specialized services:

service discovery -> service mesh tools (AppMesh, Linkerd)
service communication -> messaging and event streaming platforms (Kafka, SQS)
request routing, rate limiting, auth -> API gateways
logging and monitoring -> observability tools (CloudWatch, CloudTrail)
orchestration -> workflow engines (Step Functions)

What remained were microservices themselves:

independently developed
independently deployed
independently scaled
...units of a system, focused on isolated business capabilities.

Tech Background of the Early 2010s | Microservice Architecture — Ep. 7

Wed, 07 Jan 2026 17:00:00 +0200

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

The hardware and infrastructure assumptions shifted:

ephemeral instances became the norm
horizontal scaling became cheaper
infrastructure-as-code tools appeared and matured
instance and network failures now considered expected, not exceptional

At the same time, communication protocols and platforms stabilized around clear leaders:

HTTP as the universal transport
JSON as the universal data language
REST / gRPC as dominant API styles
Linux as the default server OS

This convergence reduced the need for protocol mediation and heavy integration layers — some of the reasons ESBs were invented. The switch from SOA was not driven only by its limitations, but also by changes in technology.