Skip to main content
Career Paths
Concepts
Bep Microservices Architecture
The Simplified Tech

Role-based learning paths to help you master cloud engineering with clarity and confidence.

Product

  • Career Paths
  • Interview Prep
  • Scenarios
  • AI Features
  • Cloud Comparison
  • Resume Builder
  • Pricing

Community

  • Join Discord

Account

  • Dashboard
  • Credits
  • Updates
  • Sign in
  • Sign up
  • Contact Support

Stay updated

Get the latest learning tips and updates. No spam, ever.

Terms of ServicePrivacy Policy

© 2026 TheSimplifiedTech. All rights reserved.

BackBack
Interactive Explainer

Microservices Architecture: Building Distributed Systems

Microservices solve organizational complexity — not technical complexity

🎯Key Takeaways
Microservices solve organizational scale — they are not inherently technically superior to monoliths.
Each service must own its own data store. Shared databases = distributed monolith.
Use synchronous (REST/gRPC) when you need immediate responses. Async events when you don't.
Circuit breakers prevent cascade failures: fail fast when downstream services are degraded.
Saga pattern for distributed transactions: compensating actions on failure rather than cross-service ACID.
Start with a monolith. Extract services when you have clear domain boundaries and team ownership.

Microservices Architecture: Building Distributed Systems

Microservices solve organizational complexity — not technical complexity

~4 min read
Be the first to complete!
What you'll learn
  • Microservices solve organizational scale — they are not inherently technically superior to monoliths.
  • Each service must own its own data store. Shared databases = distributed monolith.
  • Use synchronous (REST/gRPC) when you need immediate responses. Async events when you don't.
  • Circuit breakers prevent cascade failures: fail fast when downstream services are degraded.
  • Saga pattern for distributed transactions: compensating actions on failure rather than cross-service ACID.
  • Start with a monolith. Extract services when you have clear domain boundaries and team ownership.

Microservices: The Promise vs. the Reality

In 2023, Prime Video (Amazon) moved a microservices-based video monitoring system to a monolith. Cost dropped 90%. This contradicted the orthodoxy that microservices are always better.

Microservices Are an Organizational Pattern

Sam Newman: "Microservices are not the goal. Independent deployability is the goal. Microservices are one way to achieve it." A small team with a well-structured monolith is better than 5 engineers managing 20 microservices.

AspectMonolithMicroservices
DeploymentOne deployment unitIndependent per service
ScalingScale everything or nothingScale individual services
DevelopmentSimple local setupComplex: service discovery, networking
DataShared DB, easy JOINsEach service owns data, no cross-service JOINs
OperationsSimple: one thing to monitorComplex: distributed tracing, many logs
Team orgWorks for 1–50 engineersNeeded for 50+ engineers on same codebase
Failure modesProcess crash = everything downOne service fails = partial degradation

Designing Services: Boundaries, Communication, Data

Principles for Service Boundaries (Domain-Driven Design)

  • 🔵Bounded Context — Each service owns a coherent business domain. Order Service owns order lifecycle. Product Service owns catalog. No service reaches into another's domain.
  • 📦Single Responsibility — A service should have one reason to change. "Payment + Email + User" is a distributed monolith, not microservices.
  • 🔌Loose coupling — Services communicate via APIs or events, not by sharing databases or internal implementations.
  • 💪High cohesion — If two functions always change together, they belong in the same service.

The Distributed Monolith Anti-Pattern

Signs: all services must deploy together, services share a database, changing one service requires changing others. You have all the complexity of microservices with none of the benefits.

Communication PatternWhen to UseTradeoff
REST / gRPC (sync)When caller needs an immediate responseTemporal coupling: caller blocked if callee is slow/down
Events/Message queue (async)When caller doesn't need immediate responseEventual consistency; harder to trace failures
GraphQL federationWhen UI needs data from multiple servicesComplex schema stitching; federation overhead
Service mesh (Istio)Observability, retry, circuit breaking at infra levelSignificant operational complexity
service-communication.ts
1// Order service: sync payment (needs result) + async events (don't need to wait)
2class OrderService {
3 constructor(
4 private paymentClient: PaymentServiceClient, // gRPC
5 private kafka: Producer,
6 ) {}
7
8 async placeOrder(userId: string, items: CartItem[]): Promise<Order> {
9 // 1. SYNC: charge payment — need result to proceed
Synchronous for payment — you need the result to proceed. Can't confirm order without charge
10 const payment = await this.paymentClient.charge({
11 userId,
12 amountCents: calculateTotal(items),
13 });
14
15 if (!payment.success) {
16 throw new Error(`Payment failed: ${payment.error}`);
17 }
18
19 // 2. Save to DB
20 const order = await db.orders.create({
21 userId, items, paymentId: payment.id, status: 'confirmed'
22 });
Async event — downstream services (inventory, email) don't block the order response
23
24 // 3. ASYNC: publish event — don't wait for downstream services
25 await this.kafka.send({
26 topic: 'order-placed',
27 messages: [{ key: order.id, value: JSON.stringify({
28 orderId: order.id, userId, items,
29 })}]
30 });
31 // inventory-service, email-service, analytics consume this event
32 // Order returns immediately — no blocking on downstream
33
34 return order;
35 }
36}
37
38// Circuit Breaker: prevent cascade failures
39import CircuitBreaker from 'opossum';
40
Circuit breaker: after 50% failure rate, open circuit. Fail fast instead of timing out
41const paymentCircuitBreaker = new CircuitBreaker(
42 (req: ChargeRequest) => paymentClient.charge(req),
43 {
44 timeout: 3000,
45 errorThresholdPercentage: 50, // open if 50% of calls fail
46 resetTimeout: 30000, // retry after 30s
47 }
48);
49// When payment service is down, circuit opens
50// Subsequent calls fail immediately — don't pile up on a down service

Data Management: The Hardest Part of Microservices

The Golden Rule: One Database Per Service

If two services share a database, they are NOT microservices — they are a distributed monolith. Any schema change requires coordinating both teams. Rollbacks become impossible. Independent deployability is the whole point.

Patterns for Data Across Service Boundaries

  • 📡API Composition — Call multiple services and combine results in an aggregator. Simple but N network calls per request.
  • 🔄CQRS + Event Sourcing — Command side writes events; Query side builds read models. Powerful but complex.
  • 📋Saga Pattern — Distributed transactions via choreography (events) or orchestration (coordinator). Compensating transactions on failure.

Eventual Consistency Is the Price

In a monolith, UPDATE user.name is instantly visible everywhere. In microservices, user-service updates its DB and publishes an event. Other services' copy of user.name is eventually consistent. Design UX around this.

How this might come up in interviews

Microservices questions are really about distributed systems design and organizational architecture. Show you understand tradeoffs — don't just say "microservices are better."

Common questions:

  • When would you choose a monolith over microservices?
  • How do you handle distributed transactions across microservices?
  • What is service discovery and why does it matter?
  • How do you design API boundaries between services?

Strong answers include:

  • Mentions organizational benefits, not just technical
  • Knows the Saga pattern for distributed transactions
  • Discusses circuit breakers for resilience
  • Says "start with a monolith" for new products

Red flags:

  • "Microservices are always better"
  • No understanding of the distributed monolith anti-pattern
  • Can't explain eventual consistency in the context of microservices data

Quick check · Microservices Architecture: Building Distributed Systems

1 / 2

Two microservices share the same database. What is this called and why is it a problem?

Key takeaways

  • Microservices solve organizational scale — they are not inherently technically superior to monoliths.
  • Each service must own its own data store. Shared databases = distributed monolith.
  • Use synchronous (REST/gRPC) when you need immediate responses. Async events when you don't.
  • Circuit breakers prevent cascade failures: fail fast when downstream services are degraded.
  • Saga pattern for distributed transactions: compensating actions on failure rather than cross-service ACID.
  • Start with a monolith. Extract services when you have clear domain boundaries and team ownership.

From the books

Building Microservices — Sam Newman (2021)

Chapter 1: What Are Microservices?

Independently deployable services that model a business domain. The "independently deployable" part is the hard part most teams get wrong.

Ready to see how this works in the cloud?

Switch to Career Paths for structured paths (e.g. Developer, DevOps) and provider-specific lessons.

View role-based paths

Sign in to track your progress and mark lessons complete.

Discussion

Questions? Discuss in the community or start a thread below.

Join Discord

In-app Q&A

Sign in to start or join a thread.