System Design Architecture Patterns and APIs Syllabus

Architecture Patterns and APIs syllabus — full chapter and topic list

Expand any chapter to see its topics and sub-topics. This is the whole examinable outline for Architecture Patterns and APIs in System Design, not a summary of it.

1. 1

   Architectural Styles

   4 topics

   • Monolithic Architecture
   • Microservices Architecture
   • Service-Oriented Architecture
   • Serverless and Function-as-a-Service
2. 2

   API Design

   4 topics

   • REST and Richardson Maturity Model
   • GraphQL
   • gRPC and Protocol Buffers
   • API Versioning and Pagination
3. 3

   Event-Driven Architecture

   3 topics

   • Event Sourcing
   • CQRS
   • Choreography vs Orchestration
4. 4

   Communication Patterns

   3 topics

   • Synchronous vs Asynchronous Communication
   • Long Polling, WebSockets, SSE
   • Webhooks and Callbacks
5. 5

   Resilience Patterns

   4 topics

   • Circuit Breaker
   • Retry with Exponential Backoff and Jitter
   • Bulkhead and Timeout Patterns
   • Graceful Degradation and Fallbacks
6. 6

   Microservices Cross-Cutting Concerns

   4 topics

   • Service Mesh and Sidecar Pattern
   • Distributed Tracing
   • Centralized Logging and Metrics
   • Configuration and Secret Management

Architecture Patterns and APIs flashcards for System Design

22 of 60 cards from the Architecture Patterns and APIs deck — real questions with worked answers.

1. What is a monolithic architecture?

   A software design where all application components (UI, business logic, data access) are built and deployed as a single, unified, tightly-coupled unit running in one process.

2. List three key advantages and three disadvantages of a monolithic architecture.

   Advantages: simple to develop/test/deploy, low operational overhead, fast in-process calls (no network latency). Disadvantages: hard to scale selectively, tight coupling slows large teams, a single bug/deploy can take down the whole app.

3. What is microservices architecture?

   An architectural style structuring an application as a collection of small, independently deployable services, each owning a single business capability and its own data, communicating over the network (typically HTTP/REST, gRPC, or messaging).

4. In microservices, what does 'database per service' mean and why is it used?

   Each service owns and privately manages its own database; no other service accesses it directly. It enforces loose coupling and independent scaling/deployment, at the cost of distributed data consistency (requiring patterns like Saga).

5. Compare monolithic vs microservices on deployment, scaling, and failure isolation.

   Deployment: monolith = one unit; microservices = independent per service. Scaling: monolith = whole app; microservices = per service. Failure isolation: monolith = one failure can crash all; microservices = failures can be contained to one service.

6. What is Service-Oriented Architecture (SOA) and how does it differ from microservices?

   SOA structures software as coarse-grained, reusable services often communicating via an Enterprise Service Bus (ESB) with shared data and enterprise-wide governance. Microservices are finer-grained, decentralized, use lightweight protocols (no heavy ESB), and favor 'smart endpoints, dumb pipes' with a database per service.

7. What is an Enterprise Service Bus (ESB) in SOA?

   A centralized middleware component that handles message routing, transformation, protocol conversion, and orchestration between services in a Service-Oriented Architecture.

8. What is serverless computing / Function-as-a-Service (FaaS)?

   A cloud execution model where the provider runs code in stateless, ephemeral containers triggered by events; developers deploy individual functions and are billed only for actual execution time/resources, with no server management.

9. What is a 'cold start' in FaaS and what causes it?

   The added latency when a function is invoked and no warm container exists, so the platform must provision a container, load the runtime, and initialize code. It is caused by inactivity/scaling from zero and affects the first request after idle.

10. Name three defining characteristics of FaaS functions.

    Stateless (no persisted local state between invocations), event-driven (triggered by events like HTTP/queue/timer), and ephemeral/auto-scaling with pay-per-use billing granular to execution.

11. What is REST (Representational State Transfer)?

    An architectural style for networked APIs based on stateless client-server communication, uniform interface, resources identified by URIs, and manipulation via a standard set of methods (typically HTTP verbs).

12. List the six architectural constraints of REST.

    1) Client-Server, 2) Statelessness, 3) Cacheability, 4) Uniform Interface, 5) Layered System, 6) Code on Demand (optional).

13. What are the four levels (0-3) of the Richardson Maturity Model?

    Level 0: single URI / single HTTP method (RPC-style 'swamp of POX'). Level 1: Resources (multiple URIs, one verb). Level 2: HTTP Verbs (proper use of GET/POST/PUT/DELETE and status codes). Level 3: Hypermedia Controls (HATEOAS).

14. What does HATEOAS mean and which Richardson level does it define?

    Hypermedia As The Engine Of Application State: responses include hypermedia links telling the client what actions/transitions are available next. It defines Level 3, the highest level, of the Richardson Maturity Model.

15. Match HTTP methods GET, POST, PUT, DELETE, PATCH to their typical REST semantics.

    GET = retrieve resource (safe, idempotent); POST = create/non-idempotent action; PUT = create/replace resource fully (idempotent); DELETE = remove resource (idempotent); PATCH = partial update.

16. Which HTTP methods are idempotent and which are safe?

    Safe (no state change): GET, HEAD, OPTIONS. Idempotent (same effect if repeated): GET, HEAD, OPTIONS, PUT, DELETE. POST and PATCH are generally neither safe nor guaranteed idempotent.

17. What do HTTP status code classes 2xx, 3xx, 4xx, and 5xx represent?

    2xx = Success; 3xx = Redirection; 4xx = Client error (bad request); 5xx = Server error.

18. What is GraphQL?

    An API query language and server-side runtime (from Facebook) where clients request exactly the data they need from a single endpoint against a strongly-typed schema, avoiding over-fetching and under-fetching.

19. Name the three GraphQL operation types.

    Query (read data), Mutation (write/modify data), and Subscription (real-time updates, typically over WebSockets).

20. What are over-fetching and under-fetching, and how does GraphQL address them?

    Over-fetching = endpoint returns more data than needed; under-fetching = one endpoint returns too little, forcing multiple requests. GraphQL lets clients specify exact fields in one query, so they receive precisely what they need.

21. What is the N+1 problem in GraphQL and how is it commonly mitigated?

    When resolving a list of N items triggers 1 query for the list plus N additional queries for each item's related data. It is mitigated with batching/caching tools like DataLoader that coalesce requests within a tick.

22. What is gRPC?

    A high-performance, open-source RPC framework by Google that uses HTTP/2 for transport and Protocol Buffers as the interface definition language and binary serialization format, supporting streaming and multiple languages.

See more Architecture Patterns and APIs flashcards →

Planning Architecture Patterns and APIs for System Design

Architecture Patterns and APIs (System Design) FAQ