"What services would you build?" tests whether you can carve a system into clean modules. Monolith vs microservices, sensible boundaries, and dedicated services like image serving and a developer API.
⏱ 30 minPrereq: Units 07–08You'll be able to: decompose a system into well-bounded services
By the end of this unit
Weigh monolith vs microservices honestly (not cargo-culting micro).
Draw service boundaries around business capabilities and data ownership.
Identify services a media app needs: upload, feed, image-serving, notifications, developer API.
Handle the cross-cutting concerns microservices introduce.
Monolith vs microservices
Monolith
One deployable; simple to build, test, trace.
In-process calls — no network tax, easy transactions.
Scales as one unit; one bug can sink everything; slows large teams.
Right default early and for small teams.
vs
Microservices
Independent deploy/scale per service; team autonomy.
The mature take "I'd start with a modular monolith and split out a service only when a part needs independent scaling, has a distinct data store, or a separate team owns it. Premature microservices add distributed-systems pain before you have the scale to justify it." Saying this avoids the most common over-engineering trap.
Where to draw boundaries
Split by business capability and data ownership, not by technical layer. Each service should own its data and expose an API; others go through that API rather than reaching into its database. Good boundaries are loosely coupled (services change independently) and highly cohesive (one clear responsibility).
Services for a media app, each a business capability with its own datastore, coordinated by a gateway + event bus.
The services a media app tends to need
Upload / Post service — accepts posts, writes metadata, enqueues media processing.
Feed service — builds and serves timelines (the deep dive in Unit 15).
Image-serving service — returns the right variant/size, fronted by CDN; may resize-on-demand with caching.
Notification service — consumes events and pushes alerts/emails.
Developer / public API — a stable, versioned, rate-limited, authenticated surface for third parties, decoupled from internal services so you can evolve internals freely.
The tax microservices charge
Splitting introduces problems a monolith didn't have: distributed transactions (use sagas / eventual consistency instead of 2-phase commit), service discovery & inter-service auth, network failure handling (timeouts, retries, circuit breakers), and harder debugging (which is why Unit 13's tracing matters). Acknowledging these costs is what separates a thoughtful answer from buzzword bingo.
Circuit breakers & graceful degradation
When a downstream service is failing, a circuit breaker trips after repeated failures and fails fast (or serves a fallback) instead of piling up requests and cascading the outage. Pair with graceful degradation: if the recommendation service is down, still render the feed without recommendations. Designing for partial failure is a strong senior signal.
Quick check
A startup of 5 engineers is building an MVP. What architecture should they most likely start with?
Modular monolith. A small team moves faster with one deployable and in-process calls; premature microservices add network failures, distributed data, and ops load before there's scale or team size to need them. Extract services when a real boundary or scaling need appears.
Quick check
A clean microservice boundary means a service should…
Own its data, expose an API. Shared databases couple services together (a schema change breaks everyone), defeating the point. Cohesion around a business capability — not maximal smallness — defines a good boundary.
Practice before you move on
Decompose the photo app into 4–6 services. For each, name its single responsibility, the data it owns, and whether callers reach it synchronously or via events. Then name one cross-cutting failure (e.g., notification service down) and how the system degrades gracefully.