Episode 6 — Scaling Reliability Microservices Web3 / 6.1 — Microservice Foundations

6.1 -- Exercise Questions

50+ questions covering all five subtopics of Microservice Foundations. Use these to test comprehension, practice system design thinking, and prepare for technical interviews.

Navigation README | 6.1.a | 6.1.b | 6.1.c | 6.1.d | 6.1.e | Interview Questions | Quick Revision

How to Use This Material

  1. First pass: Answer each question in your head or on paper without looking at notes.
  2. Second pass: For questions you could not answer, re-read the relevant subtopic file, then try again.
  3. Design questions: Sketch diagrams on paper. Practice explaining your design to an imaginary interviewer.
  4. Scenario questions: There is often no single right answer. Focus on trade-offs and justification.
  5. Use the answer hints at the bottom only after attempting the question yourself.

A. Monolithic vs Microservices (6.1.a)

Conceptual

  1. Define a monolithic architecture in your own words. What are its three defining characteristics?

  2. List four advantages of a monolithic architecture.

  3. List four disadvantages of a monolithic architecture.

  4. What is the fundamental difference between how modules communicate in a monolith versus how services communicate in microservices?

  5. Explain Conway's Law and how it relates to the choice between monolith and microservices.

  6. What is a "distributed monolith"? How does it differ from a true microservices architecture?

  7. What is a modular monolith? How does it differ from both a traditional monolith and microservices?

Design

  1. You have a monolithic Express app with user management, product catalog, and order processing. Sketch how you would restructure this as microservices. What are the service boundaries? What database does each service own?

  2. Describe the Strangler Fig Pattern. For an e-commerce monolith, which module would you extract first? Justify your choice.

  3. Design a migration plan for moving a monolithic blog platform (users, posts, comments, notifications) to microservices. Identify the order of extraction and explain your reasoning.

Scenario

  1. A startup has a monolith with 200,000 lines of code, 3 developers, and 500 daily users. A new CTO proposes rewriting as microservices. What is your recommendation and why?

  2. Netflix and Etsy both serve millions of users. Netflix uses microservices; Etsy uses a monolith. Explain how both can be successful with opposite architectural choices.

B. When Microservices Make Sense (6.1.b)

Conceptual

  1. List five components of the "microservices premium" (operational overhead).

  2. What team size threshold generally suggests microservices become worthwhile? Why?

  3. Explain the YAGNI principle in the context of microservices.

  4. What is "resume-driven development" and why is it a bad reason to adopt microservices?

  5. Why are microservices particularly harmful for early-stage startups?

Design

  1. Using the decision matrix from 6.1.b (team size, deploy frequency, domain complexity, scaling variance, uptime, tech diversity, regulatory needs), score the following company and recommend an architecture:

    • 8 engineers
    • Deploy once a week
    • Single product (SaaS dashboard)
    • Uniform traffic patterns
    • 99.5% uptime target
    • All JavaScript/TypeScript
    • No regulatory isolation needed

  2. Same exercise for:

    • 40 engineers across 6 teams
    • Want to deploy multiple times per day
    • 5 distinct business domains (marketplace, payments, logistics, analytics, messaging)
    • Highly variable traffic (logistics spikes during holidays)
    • 99.99% uptime target
    • Need Python for ML, Java for payments, Node for real-time
    • PCI-DSS compliance for payment data

Scenario

  1. Your company has 12 engineers and a monolith. Deployments are painful (1-2 per week), and one team frequently blocks another. The VP of Engineering wants to move to microservices. What intermediate step would you suggest before going full microservices?

  2. A company successfully migrated to microservices 2 years ago. They recently downsized from 50 to 15 engineers. What architectural changes should they consider?

  3. Describe a scenario where a company adopted microservices, failed, and returned to a monolith. What went wrong?

C. Service Boundaries (6.1.c)

Conceptual

  1. Define "bounded context" in Domain-Driven Design. Why is it the natural unit for microservice decomposition?

  2. What is "ubiquitous language"? Why does the word "Product" mean different things in a Catalog context versus a Shipping context?

  3. Explain the difference between an Entity and a Value Object with examples.

  4. What is an Aggregate in DDD? Why is it important for microservice boundaries?

  5. What is the Anti-Corruption Layer pattern? When would you use it?

  6. Name three common mistakes when defining service boundaries.

Design

  1. Decompose a ride-sharing application (like Uber) into bounded contexts. For each context, list the key entities and 2-3 core operations.

  2. Decompose a streaming music platform (like Spotify) into bounded contexts. Identify at least 5 services.

  3. A team proposes the following microservices for a hospital management system: CreatePatient, ReadPatient, UpdatePatient, DeletePatient, CreateAppointment, ReadAppointment. What is wrong with this decomposition? Propose a better one.

  4. Draw a context map for an e-commerce system showing the relationships between Catalog, Order, Payment, and Shipping contexts. Identify which relationships are Customer-Supplier, Conformist, or Anti-Corruption Layer.

Scenario

  1. Two teams disagree about whether "reviews" belongs in the Catalog Service or a separate Reviews Service. What questions would you ask to resolve this?

  2. Your Order Service makes 15 API calls to the Inventory Service per order. A colleague suggests they should be merged. Do you agree? What factors would influence your decision?

  3. The Marketing team wants to add promotional pricing that affects products across Catalog, Orders, and Checkout. How do you handle this without violating service boundaries?

D. Database per Service (6.1.d)

Conceptual

  1. Why do shared databases break microservices? Give three specific problems.

  2. Explain the difference between strong consistency and eventual consistency. Give an example of each in an e-commerce system.

  3. What is the Saga pattern? How does it replace ACID transactions in microservices?

  4. Explain the difference between a choreography-based saga and an orchestration-based saga. When would you use each?

  5. What is a compensating transaction? Give an example.

  6. What is the API Composition pattern? When is it appropriate?

  7. What is CQRS? When should you use it and when should you avoid it?

Design

  1. Design a saga for a travel booking system that books a flight, a hotel, and a rental car. Show the happy path and the compensation path if the hotel booking fails.

  2. You have an Order Service, Inventory Service, and Payment Service. Design the database schema for each service's database. What data does each service own? What data is duplicated?

  3. A product manager wants a dashboard that shows "top 10 products by revenue this month." Revenue data is in the Order Service. Product names are in the Catalog Service. Design two approaches: API Composition and CQRS. Compare them.

Scenario

  1. An engineer proposes that the Order Service should read directly from the User database "just for performance." What do you say?

  2. Your saga has a step where the Payment Service charges a credit card. The charge succeeds, but the message acknowledging success is lost due to a network partition. What happens? How do you prevent double-charging?

  3. The read-side projection in your CQRS system is 30 seconds behind the write-side. A customer places an order and immediately checks their order history -- the order is missing. How do you handle this UX problem?

E. Service Communication Patterns (6.1.e)

Conceptual

  1. Compare synchronous and asynchronous communication in microservices. List three differences.

  2. What is temporal coupling? How does asynchronous communication eliminate it?

  3. Explain the circuit breaker pattern. Why is it essential in microservices?

  4. What is the difference between a message queue (point-to-point) and pub/sub (one-to-many)?

  5. Compare RabbitMQ and Kafka. When would you choose each?

  6. What does "idempotent" mean? Why is idempotency critical for message consumers?

  7. Explain the difference between choreography and orchestration for saga coordination.

Design

  1. Design the communication patterns for a food delivery app. The flow is: customer places order, restaurant confirms, driver is assigned, driver picks up food, driver delivers, customer rates. Which steps are synchronous? Which are asynchronous?

  2. Your system has the following call chain: API Gateway -> Order Service -> Inventory Service -> Pricing Service. Each call takes 100ms plus 10ms network overhead. What is the total latency? Propose two strategies to reduce it below 150ms.

  3. Design an event-driven notification system. When a user signs up, three things should happen: send a welcome email, create a default profile, and log an analytics event. Show the event flow using pub/sub.

Scenario

  1. Your Order Service calls the User Service synchronously. The User Service has a 1% error rate. Your Order Service processes 10,000 orders per day. How many orders fail due to User Service errors? What would you do to reduce this?

  2. A developer puts all inter-service communication through Kafka, including simple "get user by ID" queries. The response time for these queries is 500ms (Kafka consumer lag). What is wrong with this approach? What would you recommend?

  3. Your system uses choreography-based sagas. There are now 8 services in the saga flow. Debugging a failed order requires checking logs in all 8 services. What would you change?

  4. The message broker goes down for 5 minutes. What happens to your system in: (a) a synchronous REST architecture, (b) an asynchronous event-driven architecture?

Answer Hints

#Hint
1Single codebase, single deployment, shared database
2Simplicity, easy debugging, ACID transactions, low overhead
3Scaling bottlenecks, deployment risk, team coupling, technology lock-in
4Function calls (in-process) vs network calls (HTTP/gRPC/events)
5Org structure mirrors system architecture; 3 teams = ~3 services naturally
6Separately deployed services that still share a database or have tight coupling
7Single deployment, but strict module boundaries with clean interfaces
8User Service (Postgres), Catalog Service (Postgres), Order Service (Postgres) -- each with own DB
9Incremental replacement; extract lowest-risk, best-bounded module first
10Notifications first (least coupled), then Comments, then Posts, finally Users
11Stay monolith; 3 devs cannot absorb microservices overhead at 500 users
12Architecture depends on org structure, domain complexity, and deployment needs, not just scale
13Service discovery, distributed tracing, data consistency, N pipelines, monitoring x N
14~15+ engineers; below that, operational overhead exceeds team coordination overhead
15Do not build for scale you do not have yet
16Choosing tech to impress, not to solve the problem
17Slows iteration and pivoting; overhead without enough engineers to absorb it
18Score ~10 -> monolith
19Score ~30 -> microservices
20Modular monolith with enforced boundaries
21Consolidate services; fewer engineers means fewer services are sustainable
22Small team, premature adoption, operational overhead exceeded development velocity
23Boundary where a domain model is defined and consistent; maps 1:1 to a service
24Shared vocabulary within a context; Product in Catalog has images/reviews, in Shipping has weight/dimensions
25Entity: User (unique ID); Value Object: Money(100, 'USD') (defined by attributes)
26Cluster of objects treated as a unit; defines transaction boundaries within a service
27Translation layer between external and internal models; use when integrating with external systems
28Splitting too thin, splitting by technical layer, wrong boundaries causing high coupling
29Identity, Rides, Matching, Payments, Notifications, Maps/Location
30Identity, Music Catalog, Playlists, Streaming, Recommendations, Billing
31CRUD operations are not business capabilities; split by Patient, Appointment, Billing, etc.
32Catalog upstream to Order; Payment and Shipping downstream from Order
33Change frequency, team ownership, scaling needs, data ownership
34If coupling is >80% of requests, merging may be correct; evaluate data ownership
35Promotion Service owns pricing rules; other services query it or subscribe to events
36Schema coupling, connection competition, deployment coordination
37Strong: bank transfer (immediate); Eventual: order status propagation (~ms delay)
38Sequence of local transactions with compensating actions on failure
39Choreography: services react to events (2-4 steps); Orchestration: central coordinator (5+ steps)
40Undo action: if payment fails, release reserved inventory
41Aggregate data from multiple services via their APIs; good for simple reads
42Separate read/write models; use for complex queries with different read/write patterns
43Book flight -> book hotel (fails) -> compensate: cancel flight
44Order: orders, order_items; Inventory: products, stock; Payment: transactions, refunds
45API Composition: call both services, join in memory. CQRS: build denormalized view with events
46No -- breaks data ownership; use User Service API; cache if performance is the concern
47Use idempotency key; Payment Service checks if charge already exists before processing
48Read-your-writes: after creating order, read from write DB; or show optimistic UI
49Client waits vs fire-and-forget; temporal coupling vs decoupled; immediate error vs deferred
50Both services must be running; async eliminates this -- broker holds messages
51Stops calling a failing service; prevents cascading failures; auto-recovers after timeout
52Queue: one consumer per message; Pub/sub: all subscribers get every message
53RabbitMQ: task queues, moderate throughput; Kafka: event streaming, replay, high throughput
54Same message processed N times = same result; prevents double-charging, double-processing
55Choreography: decentralised, event-based; Orchestration: centralised coordinator
56Sync: place order (immediate ack); Async: restaurant confirm, driver assign, status updates
57Total: 330ms. Solutions: parallelise, cache pricing, merge inventory+pricing
58user.created event -> email subscriber, profile subscriber, analytics subscriber (3 queues)
59~100 orders/day. Add retry with backoff, circuit breaker, graceful degradation
60Kafka is not designed for request-response; use REST/gRPC for queries, Kafka for events
61Switch to orchestration for the saga; add distributed tracing (correlation IDs, Jaeger)
62(a) No impact -- direct HTTP calls work; (b) New events are lost or buffered until broker recovers

Navigation README | Interview Questions >>