Documentation Index

Fetch the complete documentation index at: https://resources.devweekends.com/llms.txt

Use this file to discover all available pages before exploring further.

​

Interview Preparation

​

Common Interview Questions

​

Architecture & Design

Order Created → Payment Charged → Inventory Reserved → Order Confirmed
                     ↓ (failure)
             Refund Payment → Release Inventory → Cancel Order

​

Communication Patterns

User → API (sync) → Order Service
                         ↓ (async)
                    Payment Event
                         ↓
                   Payment Service
                         ↓ (async)
                    Order Updated Event

// Redis-based rate limiter
const limit = await redis.incr(`ratelimit:${userId}`);
if (limit === 1) {
  await redis.expire(`ratelimit:${userId}`, 60);
}
if (limit > 100) {
  return res.status(429).json({ error: 'Rate limit exceeded' });
}

# Redis-based rate limiter (FastAPI + redis-py asyncio)
from fastapi import HTTPException
from redis.asyncio import Redis

async def check_rate_limit(redis: Redis, user_id: str) -> None:
    key = f"ratelimit:{user_id}"
    limit = await redis.incr(key)
    if limit == 1:
        await redis.expire(key, 60)
    if limit > 100:
        raise HTTPException(
            status_code=429,
            detail="Rate limit exceeded",
            headers={"Retry-After": "60"},
        )

​

Resilience & Reliability

Request → Circuit Breaker (open?)
              ↓ no
          Timeout (5s)
              ↓ success
          Return response
              ↓ failure
          Retry (3 attempts, exponential backoff)
              ↓ still failing
          Open circuit breaker
              ↓
          Return fallback

// opossum circuit breaker with fallback
const CircuitBreaker = require('opossum');

const options = {
  timeout: 5000,
  errorThresholdPercentage: 50,
  resetTimeout: 30000,
};

const breaker = new CircuitBreaker(callPaymentService, options);
breaker.fallback(() => ({ status: 'queued', message: 'Payment queued for retry' }));

async function chargeCustomer(order) {
  return await breaker.fire(order);
}

# pybreaker + tenacity for circuit breaker with retry
import pybreaker
import httpx
from tenacity import retry, stop_after_attempt, wait_exponential

payment_breaker = pybreaker.CircuitBreaker(
    fail_max=5,
    reset_timeout=30,
    exclude=[httpx.HTTPStatusError],  # do not trip on 4xx
)

@retry(
    stop=stop_after_attempt(3),
    wait=wait_exponential(multiplier=1, min=1, max=10),
)
@payment_breaker
async def call_payment_service(order: dict) -> dict:
    async with httpx.AsyncClient(timeout=5.0) as client:
        response = await client.post(
            "http://payment-service/charge",
            json=order,
        )
        response.raise_for_status()
        return response.json()

async def charge_customer(order: dict) -> dict:
    try:
        return await call_payment_service(order)
    except pybreaker.CircuitBreakerError:
        return {"status": "queued", "message": "Payment queued for retry"}

​

System Design Decision Framework

​

Architecture Decision Matrix

​

Scaling Decision Ladder

1. Caching — Can we cache the hot path? (solves 80% of scaling problems)
2. Read replicas — Can we separate reads from writes?
3. Horizontal scaling — Can we add more stateless service instances?
4. Async processing — Can we move work off the critical path?
5. Partitioning/sharding — Do we need to split the data itself?
6. CQRS — Do reads and writes have fundamentally different access patterns?

​

System Design Exercises

​

Exercise 1: Design an E-Commerce Order System

┌─────────────────────────────────────────────────────────────────────────────┐
│                    SYSTEM DESIGN: E-COMMERCE ORDERS                          │
├─────────────────────────────────────────────────────────────────────────────┤
│                                                                              │
│  Requirements:                                                               │
│  • Handle 10,000 orders/hour peak                                           │
│  • 99.9% availability                                                       │
│  • Payment processing (3rd party)                                           │
│  • Inventory management                                                     │
│  • Order tracking                                                           │
│                                                                              │
│  ┌─────────────────────────────────────────────────────────────────────┐    │
│  │                         Architecture                                 │    │
│  │                                                                      │    │
│  │  ┌────────┐    ┌─────────────┐    ┌───────────────────────────┐    │    │
│  │  │  CDN   │───▶│   API GW    │───▶│       Services            │    │    │
│  │  └────────┘    │ (Kong/NGINX)│    │  ┌─────────────────────┐  │    │    │
│  │                └─────────────┘    │  │   Order Service     │  │    │    │
│  │                       │           │  │   (PostgreSQL)      │  │    │    │
│  │                       ▼           │  └─────────────────────┘  │    │    │
│  │                ┌───────────┐      │  ┌─────────────────────┐  │    │    │
│  │                │   Redis   │      │  │   Payment Service   │  │    │    │
│  │                │  (Cache)  │      │  │   (Stripe/Adyen)    │  │    │    │
│  │                └───────────┘      │  └─────────────────────┘  │    │    │
│  │                       │           │  ┌─────────────────────┐  │    │    │
│  │                       ▼           │  │  Inventory Service  │  │    │    │
│  │                ┌───────────┐      │  │   (PostgreSQL)      │  │    │    │
│  │                │   Kafka   │◀────▶│  └─────────────────────┘  │    │    │
│  │                │  (Events) │      │  ┌─────────────────────┐  │    │    │
│  │                └───────────┘      │  │ Notification Service│  │    │    │
│  │                                   │  └─────────────────────┘  │    │    │
│  │                                   └───────────────────────────┘    │    │
│  └─────────────────────────────────────────────────────────────────────┘    │
│                                                                              │
│  Key Design Decisions:                                                       │
│  • Saga for order workflow (compensating transactions)                       │
│  • Event-driven for inventory updates                                       │
│  • CQRS for order queries (separate read model)                            │
│  • Idempotency keys for payment retry safety                               │
│                                                                              │
└─────────────────────────────────────────────────────────────────────────────┘

1. Start with requirements clarification — “How many concurrent users? What’s the read:write ratio? What’s the latency SLA?” These questions immediately signal senior thinking.
2. Estimate scale (10K orders/hour = ~3 orders/second). This is manageable for a single service, so avoid over-engineering. Mention that you would start simpler and scale only when needed.
3. Identify service boundaries using DDD — explain that Order, Payment, Inventory, and Notification are separate bounded contexts because they change for different reasons and at different rates.
4. Explain saga pattern for order workflow — walk through the happy path AND the compensation path (what happens when payment fails after inventory is reserved).
5. Discuss failure scenarios — “What if the payment service is down? We queue the payment and show the user ‘order processing.’ What if it stays down for hours? We send a notification and let them retry.”
6. Address scaling — horizontal scaling of stateless services behind a load balancer, vertical scaling of databases with read replicas.
7. Mention observability — distributed tracing across the order flow, alerting on error rate and p99 latency.

// Express order creation with outbox pattern
app.post('/orders', async (req, res) => {
  const idempotencyKey = req.headers['idempotency-key'];
  const { userId, items } = req.body;

  const existing = await db.orders.findOne({ idempotencyKey });
  if (existing) return res.status(200).json(existing);

  const order = await db.transaction(async (tx) => {
    const created = await tx.orders.create({
      userId,
      items,
      status: 'PENDING',
      idempotencyKey,
    });
    await tx.outbox.create({
      aggregateId: created.id,
      eventType: 'OrderCreated',
      payload: created,
    });
    return created;
  });

  res.status(202).json(order);
});

# FastAPI order creation with outbox pattern
from fastapi import FastAPI, Header, HTTPException
from pydantic import BaseModel
from sqlalchemy.ext.asyncio import AsyncSession
from typing import Annotated

app = FastAPI()

class OrderItem(BaseModel):
    sku: str
    quantity: int

class CreateOrderRequest(BaseModel):
    user_id: str
    items: list[OrderItem]

@app.post("/orders", status_code=202)
async def create_order(
    payload: CreateOrderRequest,
    idempotency_key: Annotated[str, Header(alias="Idempotency-Key")],
    session: AsyncSession,
) -> dict:
    existing = await session.get_order_by_idempotency_key(idempotency_key)
    if existing:
        return existing.to_dict()

    async with session.begin():
        order = await session.create_order(
            user_id=payload.user_id,
            items=[item.model_dump() for item in payload.items],
            status="PENDING",
            idempotency_key=idempotency_key,
        )
        await session.create_outbox_event(
            aggregate_id=order.id,
            event_type="OrderCreated",
            payload=order.to_dict(),
        )
    return order.to_dict()

​

Exercise 2: Design URL Shortener

• 100M URLs/month
• Redirect latency under 100ms
• 5-year data retention

• 100M writes/month = ~40 writes/second (manageable for a single write node)
• Assume 100:1 read/write ratio = ~4,000 reads/second (need caching)
• 100M URLs * 12 months * 5 years * ~500 bytes = ~300GB total storage (fits on one machine)
• Short code length: 62^7 = 3.5 trillion combinations (more than enough for 6B URLs over 5 years)

• Read path: Client hits CDN/cache first (Redis), cache miss goes to DB. With 90%+ cache hit rate, p99 stays under 100ms easily.
• Write path: Generate short code via Base62 encoding of a distributed counter (Twitter Snowflake pattern). Write to DB, warm the cache.
• Edge case — hash collisions: If using hashing instead of a counter, two different URLs can produce the same short code. Solution: check-and-retry, or use a counter-based approach that guarantees uniqueness by construction.
• Edge case — expired URLs: After 5 years, do you reuse codes? If yes, a redirect to a deleted URL could serve a different destination. Safest approach: never reuse codes; storage is cheap.

// Redirect endpoint -- cache-aside pattern
app.get('/:code', async (req, res) => {
  const { code } = req.params;
  const cached = await redis.get(`url:${code}`);
  if (cached) return res.redirect(301, cached);

  const row = await db.urls.findOne({ code });
  if (!row) return res.status(404).send('Not found');

  await redis.set(`url:${code}`, row.longUrl, 'EX', 86400);
  return res.redirect(301, row.longUrl);
});

# FastAPI redirect -- cache-aside pattern
from fastapi import FastAPI, HTTPException
from fastapi.responses import RedirectResponse
from redis.asyncio import Redis

app = FastAPI()

@app.get("/{code}")
async def redirect_short_url(
    code: str,
    redis: Redis,
    db: DatabaseSession,
) -> RedirectResponse:
    cached = await redis.get(f"url:{code}")
    if cached:
        return RedirectResponse(url=cached, status_code=301)

    row = await db.find_url_by_code(code)
    if not row:
        raise HTTPException(status_code=404, detail="Not found")

    await redis.set(f"url:{code}", row.long_url, ex=86_400)
    return RedirectResponse(url=row.long_url, status_code=301)

​

Exercise 3: Design Notification Service

• Multi-channel (email, SMS, push)
• Template support
• Delivery guarantees
• Rate limiting

• Message queue for reliability: Each notification becomes a message in Kafka/SQS. Channel-specific consumer groups (email-worker, sms-worker, push-worker) process independently.
• Dead letter queue for failures: After 3 retries, move to DLQ for manual review. Never silently drop notifications.
• Priority queues: Password reset emails are urgent (process within seconds). Marketing emails are not (batch process hourly). Use separate queues or priority levels.
• Idempotency for retries: Use a deduplication key (e.g., notification:{userId}:{type}:{orderId}) to prevent sending the same notification twice.
• Edge case — user unsubscribed mid-delivery: Check opt-out status at delivery time, not just at enqueue time. A user could unsubscribe between when the message was queued and when it is processed.
• Edge case — provider outage: If SendGrid is down, fail over to a secondary provider (Mailgun). Store provider-agnostic templates that render per-provider at send time.

// KafkaJS email worker
const { Kafka } = require('kafkajs');

const kafka = new Kafka({ clientId: 'email-worker', brokers: ['kafka:9092'] });
const consumer = kafka.consumer({ groupId: 'email-workers' });

await consumer.subscribe({ topic: 'notifications.email', fromBeginning: false });
await consumer.run({
  eachMessage: async ({ message }) => {
    const payload = JSON.parse(message.value.toString());
    const sent = await redis.get(`sent:${payload.id}`);
    if (sent) return;

    try {
      await sendgrid.send({
        to: payload.to,
        from: 'noreply@shop.com',
        templateId: payload.templateId,
        dynamicTemplateData: payload.data,
      });
      await redis.set(`sent:${payload.id}`, '1', 'EX', 86400 * 7);
    } catch (err) {
      if (err.code >= 500) throw err; // trigger redelivery
      await moveToDeadLetter(payload, err);
    }
  },
});

# aiokafka email worker with idempotency
import json
import logging
from aiokafka import AIOKafkaConsumer
from redis.asyncio import Redis
import httpx

log = logging.getLogger(__name__)

async def run_email_worker(redis: Redis) -> None:
    consumer = AIOKafkaConsumer(
        "notifications.email",
        bootstrap_servers="kafka:9092",
        group_id="email-workers",
        enable_auto_commit=False,
        auto_offset_reset="latest",
    )
    await consumer.start()
    try:
        async for message in consumer:
            payload = json.loads(message.value)
            notification_id = payload["id"]

            already_sent = await redis.get(f"sent:{notification_id}")
            if already_sent:
                await consumer.commit()
                continue

            try:
                await send_via_sendgrid(payload)
                await redis.set(f"sent:{notification_id}", "1", ex=86_400 * 7)
                await consumer.commit()
            except httpx.HTTPStatusError as err:
                if err.response.status_code >= 500:
                    raise  # do not commit -- redeliver
                await move_to_dead_letter(payload, str(err))
                await consumer.commit()
    finally:
        await consumer.stop()

async def send_via_sendgrid(payload: dict) -> None:
    async with httpx.AsyncClient(timeout=10.0) as client:
        response = await client.post(
            "https://api.sendgrid.com/v3/mail/send",
            json={
                "personalizations": [{
                    "to": [{"email": payload["to"]}],
                    "dynamic_template_data": payload["data"],
                }],
                "from": {"email": "noreply@shop.com"},
                "template_id": payload["template_id"],
            },
            headers={"Authorization": f"Bearer {SENDGRID_API_KEY}"},
        )
        response.raise_for_status()

​

Behavioral Questions

​

Follow-up Chains: When Things Break

​

Quick Reference Card

┌─────────────────────────────────────────────────────────────────────────────┐
│                    MICROSERVICES INTERVIEW CHEAT SHEET                       │
├─────────────────────────────────────────────────────────────────────────────┤
│                                                                              │
│  PATTERNS TO KNOW:                                                           │
│  ─────────────────                                                          │
│  • API Gateway          • Circuit Breaker      • Event Sourcing             │
│  • Service Discovery    • Saga Pattern         • CQRS                       │
│  • Database per Service • Outbox Pattern       • Strangler Fig              │
│                                                                              │
│  COMMUNICATION:                                                              │
│  ──────────────                                                              │
│  Sync: REST, gRPC       Async: Kafka, RabbitMQ, Events                      │
│                                                                              │
│  DATA CONSISTENCY:                                                           │
│  ─────────────────                                                          │
│  • Eventual consistency (preferred)                                         │
│  • Saga for distributed transactions                                        │
│  • Idempotency for retries                                                  │
│                                                                              │
│  RESILIENCE:                                                                 │
│  ───────────                                                                 │
│  Circuit Breaker → Retry → Timeout → Fallback → Bulkhead                   │
│                                                                              │
│  OBSERVABILITY:                                                              │
│  ──────────────                                                              │
│  Logs + Metrics + Traces = Complete visibility                              │
│  RED: Rate, Errors, Duration                                                │
│                                                                              │
│  COMMON PITFALLS:                                                            │
│  ────────────────                                                           │
│  • Distributed monolith (too coupled)                                       │
│  • Wrong service boundaries                                                 │
│  • Ignoring network failures                                                │
│  • Premature microservices                                                  │
│                                                                              │
│  INTERVIEW TIPS:                                                             │
│  ───────────────                                                            │
│  1. Always clarify requirements first                                       │
│  2. Start simple, add complexity as needed                                  │
│  3. Discuss trade-offs explicitly                                           │
│  4. Mention failure scenarios                                               │
│  5. Reference real experience                                               │
│                                                                              │
└─────────────────────────────────────────────────────────────────────────────┘

​

Interview Tips

​

Summary

​

Next Steps

​

Interview Deep-Dive

​

Structured Answer Frameworks: STAR + Technical Scaffolding

​

The STAR-T framework (STAR + Technical)

1. Situation (10-15 seconds): Context and stakes. Team size, service scope, scale, business impact. “Two years ago, I was tech lead on the payments platform at a fintech with ~40 engineers and $X billion in annual transaction volume.”
2. Task (10 seconds): The specific problem you were solving. “We had a recurring outage pattern where a single slow downstream provider would cascade through our synchronous call chain and take down the whole checkout.”
3. Action (60-90 seconds): The technical approach, with trade-offs explicit. “We layered three mitigations. First, a bulkhead per downstream — each provider got its own thread pool so exhaustion was contained. Second, a circuit breaker with 50% error threshold over 20 requests. Third, a fallback to a synchronous-but-queued pattern: if the breaker was open, we wrote the charge intent to Kafka and returned 202 Accepted with a polling endpoint. The trade-off we accepted was brief user-visible delay over cascading failures — we discussed it with Product and agreed the UX was acceptable.”
4. Result (20-30 seconds): Measurable outcome with numbers. “Over the next two quarters, cascading failures went from ~4 per quarter to zero. P99 checkout latency during downstream incidents dropped from 8s to 1.2s. The team adopted the pattern as a template for other integrations.”
5. Technical follow-up hook (10 seconds): Invite the natural next question. “Happy to go deeper on how we tuned the circuit breaker or how we handled the async-ification of what was previously synchronous UX.”

​

The “Pressure Test” framework for design questions

1. Clarify (2-3 questions): “Before I start — is this for B2C or B2B traffic? What is the expected scale? What is the availability SLA?” This signals seniority immediately.
2. Back-of-envelope math (30 seconds): “At 10,000 orders/hour, that is about 3 per second peak — manageable on a single write node. Read-heavy at 100:1 ratio means 300 reads per second, so cache matters.”
3. Draw the boundary lines (60 seconds): “I see four bounded contexts: Order, Payment, Inventory, Notification. Each owns its data. They communicate via events for state changes, REST for queries.”
4. Walk the happy path (2 minutes): Trace one user action through the whole system. Mention the DB writes, the events published, the caches populated.
5. Walk a failure path (2 minutes): “Now let us trace what happens when the payment provider is down. We circuit-break, queue the charge, return 202, retry in background.”
6. Call out the uncomfortable trade-offs (1 minute): “The place I would lose sleep: during the pay-after-202 window, the order exists but is unpaid. If the user thinks they paid and we fail to retry, we lose money. I would mitigate with a reconciliation job and strong observability on the pending-payment state.”
7. Invite the follow-up: “Where would you like me to go deeper?”