Skip to main content

Module Quiz

Complete this quiz after finishing all concept and practice pages. Treat it closed-book on a first pass; then review.

Current Module Questions​

Question 1: The Microservices Distillation​

Which single property is the strongest test for whether something is a microservice, rather than just a service?

Answer: Independent deployability. If changing one service requires a coordinated deploy of another service, it is not a microservice regardless of repo layout, containerization, or language choice.

Solution Walkthrough:

  1. Team ownership and bounded scope matter, but both are often present even in distributed-monolith setups.
  2. Independent deployability is the property that breaks under any real coupling (shared DB, shared DTOs, lockstep contract changes).
  3. That is why it is also the property stressed by Fowler, Newman, and Richardson as the acid test.

If You Got This Wrong: Revisit Cluster 1, Concept 01.

Question 2: Right-Size the Service -- Scenario A​

A 6-engineer team is considering splitting their modular monolith into 10 microservices. They have manual deploys, no distributed tracing, and one on-call person rotating weekly. What is your recommendation?

Answer: Stay with the modular monolith and invest in CI/CD, tracing, and on-call depth first. Ten services for six people produces one service per 0.6 engineers and 10 new on-call surfaces; the cost model is clearly against them.

Common Errors:

  • Recommending "start with 2-3 services" -- that still imposes the full operational overhead on a team that lacks the capabilities.
  • Treating microservices as the "grown-up" answer and the monolith as transitional.

If You Got This Wrong: Revisit Cluster 1, Concept 02.

Question 3: Strangler-Fig​

Why does strangler-fig migration succeed where big-bang rewrites fail?

Answer: Because the system stays integrated at every step. A façade/router in the monolith always routes to either the old code or the new service, and the business continues to ship features while the extraction proceeds. Big-bang rewrites require feature freeze and lose to moving business targets.

Question 4: Bounded Context = Service?​

Is a bounded context the same as a microservice? Justify.

Answer: No. A bounded context is a semantic boundary: where a model and ubiquitous language apply consistently. A microservice is a deployment unit that usually spans one bounded context. The rule is one bounded context per service, possibly multiple services per context -- never a service that spans two contexts. A service spanning two contexts re-creates the "product means two things" coupling that bounded contexts exist to prevent.

Question 5: Right-Size the Service -- Scenario B​

Your colleague proposes a "Customer Service" that exposes GET/POST/PUT/DELETE /customers, a "Product Service" with the same pattern, and an "Order Service" that orchestrates both. What anti-pattern is this, and what should you propose instead?

Answer: Entity-service anti-pattern. Each service is a network-mounted database, and the business logic (validate email uniqueness, promote to VIP, confirm order, reserve stock) lives in callers, which reinvent it independently. Propose capability-scoped services -- e.g., Accounts Service (createAccount, requestEmailChange, deactivateAccount), Catalog Service (publishProduct, deprecateProduct), Orders Service (checkout, cancelOrder) -- each owning the verbs and the data they govern.

If You Got This Wrong: Revisit Cluster 2, Concept 06.

Question 6: Database-Per-Service​

A colleague suggests keeping one PostgreSQL instance but giving each service its own schema to "simplify ops." Is this OK? Why or why not?

Answer: Separate schemas are fine and often preferred operationally. What matters is that each table is read and written by exactly one service -- through its own schema. If two services query or write each other's tables (even across schemas in the same instance), it becomes a shared database with extra steps: any schema change is a coordinated deploy, and invariants become ambiguous. Database-per-service is a logical-ownership rule, not a hardware-isolation rule.

Question 7: Contract Compatibility​

Which of the following changes to an existing sync API are safe to ship without coordinating consumers? Which are breaking?

a) Add a new optional field to a response. b) Add a new required field to a request. c) Rename an existing response field. d) Add a new enum value to a response field. e) Relax a validation (accept more inputs).

Answer:

  • a) Safe.
  • b) Breaking (existing clients do not send it).
  • c) Breaking (unless via expand-contract: add new, migrate consumers, remove old).
  • d) Safe only if consumers are tolerant readers; otherwise breaking.
  • e) Safe.

Question 8: Consumer-Driven Contract Testing​

Why is CDC consumer-driven rather than provider-driven?

Answer: Because only the consumer knows what it actually depends on. A provider-driven contract tests what the provider meant to expose; it can pass while real consumers break, because they may be depending on undocumented fields, on specific enum values, or on a subset of the API the provider didn't consider critical. The consumer is the authoritative source for "what shape I actually need."

Question 9: Sync vs Async​

Convert this synchronous call chain to a more resilient design, and justify: Frontend -> Orders -> Payments -> Inventory -> Fulfillment.

Answer: Keep Orders -> Payments synchronous (the user needs payment confirmation). Make the rest asynchronous: Orders emits OrderConfirmed on the bus, and Inventory and Fulfillment consume it independently. The user-critical path becomes two hops instead of four, the failure probability drops, and Inventory/Fulfillment downtime no longer breaks checkout.

Question 10: Resilience Primitives​

Why is a timeout alone insufficient protection for a slow downstream?

Answer: A timeout alone means every request pays the timeout's full cost while the downstream is unhealthy -- threads stay parked, queues build up, and users see the maximum latency. A circuit breaker in addition converts this to fast-fail after a threshold of failures, plus a fallback, so you stop wasting resources on a known-bad dependency.

Question 11: Right-Size the Service -- Scenario C​

A team has an existing 30-service microservices architecture. Deploy frequency is lower than when they had a monolith. Three services share one database. Every API change requires coordinated deploys across 4+ services. What is their problem, and what do you recommend?

Answer: Classic distributed-monolith. Shared DB and shared/lockstep contracts eliminate the deployability benefit. Recommendation:

  1. Database surgery: move each shared table to exactly one owning service; consumers switch to API or events.
  2. Contract versioning + CDC: adopt expand-contract; add CDC tests as merge gates.
  3. Reduce call-chain depth: convert at least one sync fan-out per major flow to async events.
  4. Optional: consolidate some services back into capability-scoped units if the 30-service split was also entity-driven.

Do this service-by-service with strangler-fig, not in a quarter-long freeze.

Question 12: Distributed Tracing​

What specifically is needed, at each service, for distributed tracing to work end-to-end on a single request?

Answer: Every service must:

  1. Accept the traceparent header (and optionally tracestate) on incoming requests.
  2. Propagate that header (with the service's own span ID as the new parent) on every outgoing call, including async events (put it in the event envelope).
  3. Stamp the trace_id into every log line.

Missing any of the three breaks the trace from that service onward.

Question 13: Expand-Contract​

Describe the expand-contract pattern for renaming a field user_id to customer_id in a response. What is the customer-visible behavior during each phase?

Answer:

  • Expand. Producer adds customer_id alongside user_id; both fields carry the same value. Safe for every consumer -- old consumers read user_id, new consumers read customer_id.
  • Migrate. Each consumer, at its own pace, switches to reading customer_id. CDC tests tell the producer when all consumers have moved.
  • Contract. Producer removes user_id. No consumer breaks, because none depend on it anymore.

Question 14: Conway's Law​

Your org has 3 teams and 15 microservices. What prediction does Conway's Law make about what the architecture will look like in 12 months?

Answer: It will drift toward 3 deployment clusters, one per team, regardless of how the services are nominally organized. Shared services will become team bottlenecks. The only way to sustain 15 independently-evolving services is to have ~15/3 = 5+ teams that can actually own them, or to consolidate to 3-6 services that match the team boundaries.

Question 15: Team Topology​

What is the difference between a platform team and a shared-service team, and why does it matter?

Answer: A platform team builds an internal product -- pipelines, observability, registries, mesh config -- consumed via self-service, with its own backlog, roadmap, and product mindset. A shared-service team does work on behalf of other teams when asked. Platform teams scale because their users self-serve; shared-service teams become bottlenecks because every consumer's feature request is serialized through them. The difference is the single most common reason microservices platforms stall.

Interleaved Review Questions​

Prior Module Question 1 (S7 M3, Bounded Contexts)​

Why would two teams call the same entity by the same name and mean different things, and what does DDD recommend when they do?

Answer: Because the term is meaningful in two different bounded contexts with different concerns. DDD recommends explicit context maps, and at the integration point either an anticorruption layer (one side translates the other's model) or a published language (both sides agree on a shared integration schema that is neither's internal model).

Prior Module Question 2 (S7 M2, Architecture Patterns)​

Why is a modular monolith often a better first architecture than microservices for a new product?

Answer: Because you have not yet discovered the real seams under production load, operational overhead is a fixed cost microservices impose regardless of team size, and refactoring module boundaries inside one process is cheap compared to refactoring service boundaries across the network.

Prior Module Question 3 (S6, Data Layer)​

Why does ACID consistency become harder across multiple services?

Answer: A single-database transaction cannot span services that own separate databases. Cross-service consistency must be eventual, implemented via sagas, compensating actions, outbox patterns, or event-carried state transfer -- never via distributed two-phase commit across OLTP databases in production.

Prior Module Question 4 (S5, Design)​

Why is high cohesion + low coupling a goal for both classes and services?

Answer: Same underlying reason at two scales: cohesion means one unit owns a single responsibility and can be reasoned about in isolation; low coupling means changing that unit does not force changes in others. Services are "classes at runtime over the network," and the same forces apply.

Prior Module Question 5 (S4, Systems Programming)​

Why is "the network is reliable" one of the famous fallacies of distributed computing?

Answer: Because every real network has partitions, latency spikes, packet loss, misrouted traffic, DNS issues, and asymmetric failure. Any design that assumes the network will always deliver will fail in production. Microservices sit directly on top of this assumption, which is why the resilience primitives of concept 12 are mandatory, not optional.

Self-Assessment and Remediation​

Scoring and Advancement Criteria​

Mastery Level (90-100% correct):

  • Ready to advance to Module 3: Event-Driven Architecture.
  • Evidence: you can argue both for and against microservices given a concrete team and product, and walk through a full decomposition + contract + resilience sketch on demand.

Proficient Level (75-89% correct):

  • Targeted review of specifically missed questions. Redo the corresponding mini drill.
  • For each missed cluster, write a one-paragraph Feynman note in your own words.

Developing Level (60-74% correct):

  • Rework practice pages 01 and 02 on a different industry (switch from e-commerce to SaaS or logistics).
  • Re-read the three concepts most frequently missed.
  • Retake the quiz one week later.

Insufficient Level (<60% correct):

  • Return to Semester 7 Module 3 (Bounded Contexts) first; this module depends heavily on the DDD intuition.
  • Then re-read this module's concept pages in order without skipping drills.
  • Retake the quiz after a full concept+practice replay.

Remediation Resources​