Microservices Patterns — Series 2

Preview — 3 of 10 questions

A team needs to migrate a large legacy monolith to microservices, but a full rewrite is too risky to do all at once. What's the strangler fig pattern, and how does it reduce that risk?

AThe strangler fig pattern gradually routes specific pieces of functionality away from the monolith to new microservices one at a time (often via a routing layer/proxy in front of both), while the rest of the traffic keeps flowing to the still-functioning monolith. Over time, more and more functionality is "strangled" out of the monolith into services, until eventually little or nothing is left of the original — all without ever needing a risky, all-at-once cutover

BThe strangler fig pattern means shutting down the monolith completely on day one and running entirely on unfinished microservices immediately

CThe strangler fig pattern requires deleting the monolith's source code before writing a single line of the new services

DThe strangler fig pattern only applies to frontend applications and has no relevance to backend architecture

In a microservices architecture, why do teams typically give each service its own dedicated database, rather than having all services share one common database?

AA shared single database across all services is always strictly better and is the recommended default for microservices

BDatabase-per-service means every service must use the exact same database technology (e.g., all PostgreSQL) for consistency

CSharing one database across services tightly couples them at the data layer — any service can accidentally depend on another's internal schema, making independent deployments risky (a schema change for one service could silently break another). Database-per-service enforces that each service owns and can only access its own data store, forcing inter-service data needs to go through the owning service's actual API — preserving each service's ability to change its schema and deploy independently

DDatabase-per-service is only a theoretical recommendation that's never actually implemented in real production systems

A company has both a mobile app and a web app consuming the same set of backend microservices, but each client needs data shaped and aggregated differently. What's the Backend for Frontend (BFF) pattern?

ABFF means building one single, generic backend API that every client type must adapt to identically, with no client-specific tailoring at all

BA BFF is a dedicated backend layer built specifically for one particular client (or client type), sitting between that client and the underlying microservices — it aggregates and reshapes data from multiple services into exactly the format that specific client needs, letting each client type (mobile, web, etc.) have an API tailored to it, instead of one generic API trying to serve every client's differing needs equally well

CBFF is a database replication technique unrelated to API design

DBFF requires every client to directly call every microservice individually, with no intermediary layer at all

Answer all 10 questions (7 more), see explanations for every answer, and track your score.