Microservices Patterns

Microservices Patterns: Building Your City of Smart Helpers 🏙️

Imagine you want to build the world’s best pizza restaurant. You could hire ONE person who takes orders, makes dough, adds toppings, bakes pizzas, handles payments, and delivers. But what happens when 100 customers arrive? That one person would collapse!

What if instead, you had a TEAM? One person takes orders. Another makes dough. Someone else adds toppings. A baker handles the oven. A cashier manages payments. A driver delivers.

That’s Microservices Architecture — breaking one giant job into many small, focused helpers who work together!

🏗️ Microservices Architecture

The Big Idea

Instead of building ONE massive app that does everything (called a “monolith”), you build MANY small apps. Each small app does ONE thing really well.

graph LR
    A["Old Way: One Giant App"] --> B["Order System"]
    A --> C["Payment System"]
    A --> D["Delivery System"]
    A --> E["User System"]

    F["New Way: Microservices"] --> G["Order Service"]
    F --> H["Payment Service"]
    F --> I["Delivery Service"]
    F --> J["User Service"]

Real Life Example

Amazon doesn’t run on one program. It has:

• A Search Service that finds products
• A Cart Service that remembers what you want
• A Payment Service that handles your money
• A Recommendation Service that suggests items
• A Delivery Service that tracks your package

Each service is like a separate small business, doing its job perfectly!

Why This Matters

🔍 Service Discovery

The Problem

Picture this: You have 50 different services running. The Order Service needs to talk to the Payment Service. But HOW does it find it? The Payment Service could be running on any computer!

It’s like arriving in a new city and needing to find a specific shop — you need a phone book or map!

The Solution

Service Discovery is like a magical directory where every service registers itself:

“Hi! I’m the Payment Service, and you can find me at address 192.168.1.42, port 8080!”

graph TD
    A["Payment Service Starts"] --> B["Registers with Discovery"]
    C["Order Service"] --> D{Asks Discovery}
    D --> E["Gets Payment Address"]
    E --> F["Talks to Payment"]

Real Life Example

Netflix uses a tool called Eureka for service discovery. When any service starts, it says “I’m alive!” to Eureka. When another service needs to find it, it asks Eureka for directions.

Simple Code Idea:

# Payment Service registers itself
registry.register("payment-service",
                  "192.168.1.42:8080")

# Order Service finds Payment
address = registry.find("payment-service")
# Returns: "192.168.1.42:8080"

⚖️ CAP Theorem

The Impossible Triangle

Imagine you’re playing a game where you can only choose 2 out of 3 magical powers:

1. Consistency — Everyone always sees the same information
2. Availability — The system always responds (never says “I’m busy”)
3. Partition Tolerance — System works even when some parts can’t talk

THE RULE: You can ONLY have 2 out of 3. It’s impossible to have all three!

graph TD
    A["CAP Theorem"] --> B["Pick 2!"]
    B --> C["CP: Consistent + Partition Tolerant"]
    B --> D["AP: Available + Partition Tolerant"]
    B --> E["CA: Consistent + Available"]
    C --> F["Banks, Payments"]
    D --> G["Social Media, DNS"]
    E --> H["Single Server Only"]

Real Examples

Simple Explanation

Consistency: If you deposit $100, everyone sees $100 immediately.

Availability: When you ask “what’s my balance?”, you always get an answer.

Partition Tolerance: Even if one server can’t talk to another, the system keeps working.

📊 Consistency Models

What’s Consistency?

When you save data, how quickly does everyone else see it? That’s what consistency models define!

Types of Consistency

Strong Consistency 💪

The moment you write something, EVERYONE sees it immediately.

Like updating a shared Google Doc — when you type, everyone sees it right away!

Eventual Consistency ⏰

After you write something, everyone will EVENTUALLY see it… just not right away.

Like posting on social media — your friend in another country might see it 2 seconds later.

Causal Consistency 🔗

Related things happen in order. Unrelated things can be out of order.

Like a conversation: “Hi” must come before “Hello!” response.

graph LR
    A["You Write Data"] --> B{Consistency Type}
    B --> C["Strong: Everyone sees NOW"]
    B --> D["Eventual: Seconds/Minutes later"]
    B --> E["Causal: Order preserved"]

Real Example

Instagram Comments:

• You comment on a photo
• Your friend in Japan might see it 3 seconds later
• That’s eventual consistency — and it’s okay!

Bank Transfer:

• You send $500 to mom
• Her account MUST show $500 immediately
• That’s strong consistency — critical for money!

🔌 Circuit Breaker Pattern

The Problem

Imagine you call a pizza shop that’s closed. You wait… and wait… no answer. You try again. And again. You waste all your time!

In software, if Service A keeps calling Service B (which is broken), Service A gets stuck waiting forever!

The Solution

A Circuit Breaker is like a smart guard:

1. CLOSED (Normal): Requests go through ✅
2. OPEN (Broken): Requests blocked immediately ❌
3. HALF-OPEN (Testing): Try one request to see if it works 🔄

graph TD
    A["CLOSED - Normal"] -->|Too Many Failures| B["OPEN - Blocked"]
    B -->|Wait Timer| C["HALF-OPEN - Testing"]
    C -->|Test Fails| B
    C -->|Test Works| A

Real Example

Netflix uses circuit breakers everywhere:

try:
    response = call_movie_service()
except TooManyFailures:
    # Circuit OPEN!
    show_cached_movies()  # Backup plan
    # Don't keep calling broken service

When the recommendation service breaks, Netflix shows you “Popular Movies” instead of personalized recommendations. The app still works!

🔄 Retry Patterns

The Problem

Sometimes things fail not because they’re broken, but because they’re BUSY. The network hiccupped. The server was updating.

If you try again, it might work!

The Solution

Retry Pattern means: If it fails, wait a bit, try again!

Types of Retries

Fixed Retry:

Wait 2 seconds, try again
Wait 2 seconds, try again
Wait 2 seconds, try again

Exponential Backoff: (SMART!)

Wait 1 second, try again
Wait 2 seconds, try again
Wait 4 seconds, try again
Wait 8 seconds, try again

The wait time DOUBLES each time! This prevents overwhelming a struggling server.

Jitter: Add random time so everyone doesn’t retry at the exact same moment.

graph LR
    A["Request Fails"] --> B["Wait"]
    B --> C["Retry"]
    C -->|Success| D["Done!"]
    C -->|Fail| E{Max Retries?}
    E -->|No| B
    E -->|Yes| F["Give Up"]

Real Example

AWS SDK automatically retries failed requests with exponential backoff:

• First retry: 100ms
• Second retry: 200ms
• Third retry: 400ms
• Fourth retry: 800ms

🔐 Idempotency

The Big Word, Simple Idea

Idempotent means: Doing something once OR doing it 100 times gives the SAME result.

Why It Matters

Imagine clicking “Pay $50” and your internet glitches. Did the payment go through? You click again just to be sure…

WITHOUT Idempotency: You might be charged $100 (twice)! 😱

WITH Idempotency: Even if you click 10 times, you’re only charged $50! ✅

How It Works

Every request gets a unique ID:

Request #ABC123: Pay $50

# First time: Payment processed! ✅
# Second time: "Already done ABC123" ✅
# Third time: "Already done ABC123" ✅

The server remembers: “I already handled ABC123, so I’ll just say ‘success’ again without charging again.”

graph TD
    A["Request with ID: XYZ"] --> B{Seen This ID?}
    B -->|No| C["Process Request"]
    B -->|Yes| D["Return Previous Result"]
    C --> E["Save ID + Result"]
    E --> F["Return Result"]

Real Examples

⏱️ Timeout Strategies

The Problem

You ask a service for data. How long should you wait?

• Wait too short: You give up on requests that would succeed
• Wait too long: Your whole system freezes waiting

The Solution

Set smart timeouts — maximum wait times for responses.

Types of Timeouts

Connection Timeout:

How long to wait while CONNECTING to the server? Usually: 1-5 seconds

Read Timeout:

Once connected, how long to wait for DATA? Usually: 5-30 seconds

Total Timeout:

Maximum time for the ENTIRE operation? Usually: 30-60 seconds

graph TD
    A["Start Request"] --> B["Connection Timeout"]
    B -->|Connected| C["Read Timeout"]
    B -->|Failed| D["Retry or Error"]
    C -->|Got Data| E["Success!"]
    C -->|Too Slow| D

Real Example

Stripe (Payment API):

# Talking to payment system
timeout = {
    "connect": 5,    # 5 seconds to connect
    "read": 30       # 30 seconds for response
}

# Payment is slow but important!
# We wait longer than a search query

Google Search:

• Timeout: ~200 milliseconds
• If a server is slow, skip it!
• Speed matters more than completeness

Timeout + Retry Together

Attempt 1: 3 second timeout... FAILED
Wait 1 second
Attempt 2: 3 second timeout... FAILED
Wait 2 seconds
Attempt 3: 3 second timeout... SUCCESS!

🎯 Putting It All Together

Imagine building an online shopping app:

1. Microservices Architecture — Separate services for cart, payments, shipping
2. Service Discovery — Services find each other automatically
3. CAP Theorem — Payments need consistency, product catalog can be eventual
4. Consistency Models — Strong for orders, eventual for reviews
5. Circuit Breaker — If shipping service is down, show “calculating…” not crash
6. Retry Patterns — Payment failed? Wait and retry with exponential backoff
7. Idempotency — Double-clicking “Buy Now” only charges once
8. Timeout Strategies — Don’t wait forever for a slow recommendation service

graph TD
    A["User Places Order"] --> B["Order Service"]
    B --> C["Service Discovery"]
    C --> D["Find Payment Service"]
    D --> E{Circuit Breaker OK?}
    E -->|Yes| F["Call Payment"]
    E -->|No| G["Show Error Fast"]
    F -->|Timeout| H["Retry with Backoff"]
    F -->|Success| I["Idempotent: Record Done"]
    H --> F
    I --> J["Order Confirmed!"]

🌟 Remember This!

You now understand the building blocks of modern cloud systems — the same patterns used by Netflix, Amazon, Google, and every major tech company! 🚀