Introduction to Microservices

Introduction

The first time I worked on a large-scale distributed system, I was overwhelmed by the complexity. Services calling services, data scattered across databases, deployments that felt like orchestrating a symphony. Through years of building and maintaining these systems, I've developed a practical understanding of when microservices make sense—and when they don't.

This article covers the fundamentals of microservice architecture, helping you make informed decisions about architectural approaches.

What Are Microservices?

Microservices architecture structures an application as a collection of loosely coupled, independently deployable services. Each service:

• Focuses on a specific business capability

• Owns its data and logic

• Communicates through well-defined APIs

• Can be developed, deployed, and scaled independently

Monolith vs Microservices

The Monolithic Approach

A monolith is a single, unified application where all components are interconnected and deployed together.

# Monolithic structure - everything in one codebase
# app/
# ├── models/
# │   ├── user.py
# │   ├── order.py
# │   └── payment.py
# ├── services/
# │   ├── user_service.py
# │   ├── order_service.py
# │   └── payment_service.py
# ├── api/
# │   └── routes.py
# └── main.py

# Everything shares the same database and process
from sqlalchemy.orm import Session
from app.models import User, Order, Payment
from app.database import get_db


class OrderService:
    """Order logic tightly coupled with user and payment."""
    
    def __init__(self, db: Session):
        self.db = db
    
    def create_order(self, user_id: int, items: list[dict]) -> Order:
        # Direct database access to user table
        user = self.db.query(User).filter(User.id == user_id).first()
        if not user:
            raise ValueError("User not found")
        
        # Create order in same transaction
        order = Order(user_id=user_id, items=items)
        self.db.add(order)
        
        # Payment processing in same transaction
        payment = Payment(order=order, amount=order.total)
        self.db.add(payment)
        
        self.db.commit()
        return order

Monolith Advantages:

• Simple to develop and deploy initially

• Easy to test end-to-end

• No network latency between components

• Single database transactions (ACID)

• Straightforward debugging

Monolith Challenges:

• Scaling requires scaling everything

• Large codebase becomes hard to understand

• Technology stack is locked

• Single point of failure

• Long deployment cycles

The Microservices Approach

# user-service/src/api/routes.py
from fastapi import FastAPI, HTTPException
from pydantic import BaseModel

app = FastAPI(title="User Service")


class UserResponse(BaseModel):
    id: int
    email: str
    name: str


@app.get("/users/{user_id}", response_model=UserResponse)
async def get_user(user_id: int):
    """User service only knows about users."""
    user = await user_repository.get(user_id)
    if not user:
        raise HTTPException(status_code=404, detail="User not found")
    return user

# order-service/src/services/order_service.py
import httpx
from src.models import Order
from src.config import settings


class OrderService:
    """Order service calls other services via HTTP."""
    
    def __init__(self, order_repository, http_client: httpx.AsyncClient):
        self.order_repository = order_repository
        self.http_client = http_client
    
    async def create_order(self, user_id: int, items: list[dict]) -> Order:
        # Call user service to verify user exists
        response = await self.http_client.get(
            f"{settings.USER_SERVICE_URL}/users/{user_id}"
        )
        if response.status_code == 404:
            raise ValueError("User not found")
        
        # Create order in order service's database
        order = await self.order_repository.create(
            user_id=user_id,
            items=items
        )
        
        # Publish event for payment service (async)
        await self.publish_event("order.created", {
            "order_id": order.id,
            "amount": order.total,
            "user_id": user_id
        })
        
        return order

Microservices Advantages:

• Independent deployment and scaling

• Technology flexibility per service

• Team autonomy and ownership

• Fault isolation

• Easier to understand individual services

Microservices Challenges:

• Distributed system complexity

• Network latency and failures

• Data consistency challenges

• Operational overhead

• Testing complexity

When to Use Microservices

Good Candidates

Use microservices when you have:

Factor	Indicator
Team Size	Multiple teams (>10 developers)
Deployment	Different release cycles needed
Scale	Components have different scaling needs
Technology	Need different tech stacks
Domain	Clear business domain boundaries
Availability	Need fault isolation

Poor Candidates

Avoid microservices when:

• Small team (< 5 developers)

• Simple CRUD application

• Tight deadlines with new team

• Unclear domain boundaries

• Limited DevOps capability

• Strong consistency requirements everywhere

The Modular Monolith Alternative

Before jumping to microservices, consider the modular monolith:

# Modular monolith structure
# app/
# ├── modules/
# │   ├── users/
# │   │   ├── __init__.py
# │   │   ├── api.py
# │   │   ├── models.py
# │   │   ├── repository.py
# │   │   └── service.py
# │   ├── orders/
# │   │   ├── __init__.py
# │   │   ├── api.py
# │   │   ├── models.py
# │   │   ├── repository.py
# │   │   └── service.py
# │   └── payments/
# │       └── ...
# ├── shared/
# │   ├── database.py
# │   └── events.py
# └── main.py

# modules/orders/service.py
from modules.users.service import UserService  # Import through public API


class OrderService:
    """Clear module boundary, but same deployment unit."""
    
    def __init__(self, order_repo, user_service: UserService):
        self.order_repo = order_repo
        self.user_service = user_service
    
    def create_order(self, user_id: int, items: list) -> Order:
        # Call through module's public interface
        user = self.user_service.get_user(user_id)
        if not user:
            raise ValueError("User not found")
        
        return self.order_repo.create(user_id=user_id, items=items)

Modular Monolith Benefits:

• Clear boundaries without distribution complexity

• Easier to extract to microservices later

• Single deployment, simpler operations

• In-process communication (fast)

• Prepare for future microservices

Conway's Law

"Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations." — Melvin Conway

Inverse Conway Maneuver

Structure teams to match desired architecture:

# Team structure influences architecture
# 
# ┌─────────────────────────────────────────────┐
# │           Traditional Structure              │
# ├─────────────────────────────────────────────┤
# │  Frontend Team → Backend Team → DBA Team    │
# │  (Horizontal layers = Layered Architecture) │
# └─────────────────────────────────────────────┘
#
# ┌─────────────────────────────────────────────┐
# │           Cross-Functional Teams             │
# ├─────────────────────────────────────────────┤
# │  User Team    │ Order Team   │ Payment Team │
# │  (FE+BE+DB)   │ (FE+BE+DB)   │ (FE+BE+DB)   │
# │  (Vertical = Microservices)                 │
# └─────────────────────────────────────────────┘

Team Ownership Model

# Each team owns their service end-to-end
from dataclasses import dataclass
from enum import Enum


class TeamResponsibility(Enum):
    DEVELOPMENT = "development"
    TESTING = "testing"
    DEPLOYMENT = "deployment"
    MONITORING = "monitoring"
    ON_CALL = "on_call"


@dataclass
class ServiceOwnership:
    """Define clear ownership for each service."""
    
    service_name: str
    team: str
    responsibilities: list[TeamResponsibility]
    
    # "You build it, you run it" - Werner Vogels, Amazon CTO
    def __post_init__(self):
        # Full ownership means all responsibilities
        self.responsibilities = list(TeamResponsibility)


# Example ownership
user_service = ServiceOwnership(
    service_name="user-service",
    team="Identity Team",
    responsibilities=[
        TeamResponsibility.DEVELOPMENT,
        TeamResponsibility.TESTING,
        TeamResponsibility.DEPLOYMENT,
        TeamResponsibility.MONITORING,
        TeamResponsibility.ON_CALL,
    ]
)

The Distributed Systems Reality

Fallacies of Distributed Computing

When you move to microservices, you're building a distributed system. Peter Deutsch's fallacies become your reality:

# The 8 Fallacies - things we wrongly assume

FALLACIES = [
    "The network is reliable",           # Networks fail
    "Latency is zero",                   # Calls take time
    "Bandwidth is infinite",             # Data transfer has limits
    "The network is secure",             # Security is your job
    "Topology doesn't change",           # Services move
    "There is one administrator",        # Many teams, many configs
    "Transport cost is zero",            # Serialization has overhead
    "The network is homogeneous",        # Different protocols exist
]


# In practice, this means:
class OrderService:
    async def create_order(self, user_id: int, items: list) -> Order:
        try:
            # Network call can fail
            user = await self.get_user_with_retry(user_id)
        except NetworkError:
            # What do we do when user service is down?
            raise ServiceUnavailable("Cannot verify user")
        
        try:
            order = await self.order_repo.create(user_id, items)
            
            # This might succeed but event publish fails
            await self.publish_event("order.created", order)
        except PublishError:
            # Order created but event not published
            # Now we have inconsistency
            await self.schedule_retry(order)
        
        return order

CAP Theorem

In distributed systems, you can only guarantee two of three:

In practice:

• CP systems: Choose consistency over availability (banking)

• AP systems: Choose availability over consistency (social media)

# Microservices typically favor AP (eventual consistency)
class OrderService:
    async def get_order_with_user(self, order_id: int) -> OrderWithUser:
        order = await self.order_repo.get(order_id)
        
        try:
            # Try to get fresh user data
            user = await self.user_client.get(order.user_id)
        except ServiceUnavailable:
            # Fall back to cached/stale data (availability over consistency)
            user = await self.user_cache.get(order.user_id)
            if not user:
                user = UnknownUser(id=order.user_id)
        
        return OrderWithUser(order=order, user=user)

Microservices Trade-offs Summary

Aspect	Monolith	Microservices
Deployment	All or nothing	Independent
Scaling	Entire app	Per service
Technology	Single stack	Polyglot
Data	Shared database	Database per service
Transactions	ACID	Eventual consistency
Testing	Simpler E2E	Complex integration
Debugging	Single process	Distributed tracing
Latency	In-process	Network overhead
Team Size	Works for small	Suits large teams
Operational	Lower	Higher

Practical Exercise

Exercise 1: Assess Your Application

Evaluate whether microservices make sense for your context:

from dataclasses import dataclass
from enum import Enum


class Score(Enum):
    LOW = 1
    MEDIUM = 2
    HIGH = 3


@dataclass
class MicroservicesAssessment:
    """Assess microservices readiness."""
    
    team_size: Score           # How large is your team?
    deployment_frequency: Score # How often do you deploy?
    scaling_variance: Score     # Do parts need different scaling?
    domain_clarity: Score       # Are business domains clear?
    devops_maturity: Score      # CI/CD, monitoring capability?
    
    @property
    def total_score(self) -> int:
        return sum([
            self.team_size.value,
            self.deployment_frequency.value,
            self.scaling_variance.value,
            self.domain_clarity.value,
            self.devops_maturity.value,
        ])
    
    @property
    def recommendation(self) -> str:
        if self.total_score >= 12:
            return "Strong candidate for microservices"
        elif self.total_score >= 8:
            return "Consider modular monolith, prepare for microservices"
        else:
            return "Stay with monolith for now"


# Example assessment
assessment = MicroservicesAssessment(
    team_size=Score.HIGH,           # 15+ developers
    deployment_frequency=Score.HIGH, # Daily deployments
    scaling_variance=Score.MEDIUM,   # Some components scale differently
    domain_clarity=Score.HIGH,       # Clear bounded contexts
    devops_maturity=Score.MEDIUM,    # Good CI/CD, basic monitoring
)

print(f"Score: {assessment.total_score}/15")
print(f"Recommendation: {assessment.recommendation}")

Exercise 2: Identify Service Boundaries

List the main capabilities of your application and potential service boundaries:

| Capability | Data Owned | Team | Deployment Needs | Service Candidate? |
|------------|------------|------|------------------|-------------------|
| User Auth  | Users, Sessions | Identity | Frequent | Yes |
| Orders     | Orders, Items | Commerce | Daily | Yes |
| Inventory  | Stock, Products | Warehouse | Weekly | Yes |
| Payments   | Transactions | Finance | Regulated | Yes |
| Reports    | None (reads) | Analytics | Monthly | Maybe (BFF) |

Key Takeaways

1. Microservices aren't always the answer - Start with a modular monolith if unsure

2. Conway's Law is real - Align architecture with team structure

3. Distributed systems are hard - Accept network failures, latency, and partial failures

4. Own your services - "You build it, you run it"

5. Start with clear boundaries - Domain-driven design helps identify services

What's Next?

With a solid understanding of what microservices are and when to use them, let's explore how to identify and define service boundaries. In Article 2: Service Decomposition Strategies, we'll cover techniques for breaking down applications into well-defined services.

---

This article is part of the Microservice Architecture 101 series.