Skip to content
API Design Learn/Capstone Case Studies
Browsing as a guest. Sign in to save your progress and earn XP as you complete chapters.

The Grand Unified API: Multi-Protocol Architecture

13 min read

You'll learn to

  • -Design one coherent system that deliberately combines REST, GraphQL, and gRPC, each where it genuinely fits best
  • -Synthesize the full course by naming which technique from which module justifies each architectural decision

This closing chapter mirrors LLD Fundamentals' schema-design capstone: rather than one more isolated case study, it works through a scenario deliberately designed to draw on nearly every module in this course, the way a real staff-level API architecture review actually unfolds.

The Scenario: A Multi-Sided Commerce Platform

Picture a platform (mirroring the Lab's own capstone level) serving three very different consumers: a rich web dashboard for sellers managing their storefront, a public developer ecosystem of third-party integrations, and a high-throughput internal system connecting order, inventory, and payment services. Each consumer genuinely needs a different protocol - this is not a contrived excuse to name-drop three technologies, it is what a real system at this scale actually requires.

Layer 1: GraphQL for the Seller Dashboard

GraphQL fits a data-dense, many-different-views dashboard well
type Query {
  seller(id: ID!): Seller
}
type Seller {
  storefront: Storefront!
  orders(first: Int, after: String): OrderConnection!
  analytics: SellerAnalytics!
}

A rich dashboard rendering many different, data-dense views (orders, analytics, storefront settings) benefits directly from GraphQL's client-specified queries - different dashboard pages fetch different slices of the same underlying seller data in one request each, using the Relay Connection pattern for paginated lists, without the backend needing a bespoke REST endpoint per dashboard view.

Layer 2: REST for the Public Developer Platform

REST is the right default for a broad, external developer ecosystem
GET /v1/orders/501
Authorization: Bearer eyJhbGc...

Third-party developers integrating from many different languages and skill levels benefit from REST's universality and simplicity far more than they would from GraphQL's steeper learning curve - this layer reuses the OAuth2 authorization code flow (for apps acting on a specific seller's behalf) and URL-path versioning from the platform module directly.

Layer 3: gRPC for Internal Service-to-Service Calls

gRPC for high-throughput internal traffic between order, inventory, and payment services
service InventoryService {
  rpc ReserveStock (ReserveStockRequest) returns (ReservationResult);
}

Internal calls between order, inventory, and payment services happen at far higher volume than any single external client's traffic, and performance and strict typing matter more here than human-readability - exactly the case for gRPC's binary format and compile-time contract enforcement from the protocol modules.

Tying the Layers Together: The Gateway

An API gateway sits in front of both the GraphQL and REST layers, handling authentication, rate limiting (tiered by plan, from the throttling chapter), and translating external requests into the internal gRPC calls that actually fulfill them - the same protocol-translation role from the gateway-design chapter, now bridging three protocols instead of two.

Resilience Threaded Throughout

  • -Idempotency keys on every payment-affecting write, regardless of which protocol layer it entered through.
  • -Circuit breakers between internal gRPC services, with fallback responses (e.g. cached inventory counts) when a dependency is struggling.
  • -The outbox pattern ensuring order-placed events are never silently lost between the order service's database write and publishing to downstream services.
  • -Deadline propagation across the internal gRPC call chain, so a slow inventory check doesn't waste payment-service resources on a request the gateway has already given up on.

On a system this large, the strongest closing move - exactly as LLD Fundamentals' capstone modeled - is naming which specific technique from which specific module justifies each decision, rather than assuming the diagram speaks for itself. A staff-level review is graded on that reasoning as much as on the architecture itself.

Interview Signal is part of Pro

See a real weak answer next to a real strong one for this exact topic.

Quiz is part of Pro

Test what you just read with a short quiz, and bank the XP.

Ready to Build This?

Design The Grand Unified API in the API Design Lab's Full System Design act.

ScaleDojo Logo
Initializing ScaleDojo