Types of System Design Interviews: Product, Infrastructure, OOD, and API Design

Here's something most prep guides skip: not all system design interviews test the same thing.

When someone says "I have a system design interview," they could mean four very different conversations. A product design interview at Meta asks you to design the backend for Instagram Stories. An infrastructure design interview at Google asks you to build a distributed key-value store. An OOD interview at Amazon asks you to model a parking lot's class hierarchy. An API design interview asks you to design the REST interface for a payment gateway.

Each type has different expectations, different scoring criteria, and different preparation strategies. The candidate who prepares for a product design interview and walks into an infrastructure design interview will spend 20 minutes talking about the wrong things.

This guide breaks down all four types so you know what to expect, how to adjust your approach, and which companies favor which type. For the full preparation framework that applies across all four types, see the complete system design interview guide.

A quick map before we dive in

The percentages are rough, based on patterns across thousands of interview reports. Product design dominates, but knowing the others prevents a nasty surprise.

Type 1: Product Design

This is the interview 70% of candidates will face. When people say "system design interview" without qualification, they almost always mean this.

What happens

The interviewer gives you a product and asks you to design the system behind it. Not the UI, not the user flows, not the wireframes. The backend architecture: how data moves, how components communicate, what databases you'd use, how the system handles scale.

The question usually sounds like:

• "Design WhatsApp"
• "Design Instagram's news feed"
• "Design a ride-sharing service like Uber"
• "Design a URL shortener like TinyURL"

You're expected to take this single sentence and turn it into a complete system architecture within 45 minutes. That means: clarifying requirements, estimating capacity, defining the API, choosing a data model, sketching the high-level architecture, deep-diving into 2-3 components, and discussing trade-offs.

What interviewers are actually scoring

Product design interviews evaluate four things simultaneously:

1. Can you break down an ambiguous product into concrete technical requirements? The interviewer deliberately gives you a vague prompt ("Design WhatsApp"). Your first job is to ask clarifying questions: Does it need group messaging? Voice calls? Read receipts? End-to-end encryption? How many users? The quality of your questions tells the interviewer whether you'd be effective in a real product meeting where the requirements are equally vague.

2. Can you design a system that actually works at scale? A chat system for 100 users is trivially different from one for 100 million. The interviewer wants to see that your architecture handles real-world traffic, not a classroom exercise. This is where capacity estimation matters.

3. Can you reason about trade-offs? Every design decision has a cost. SQL vs NoSQL, push vs pull, strong vs eventual consistency. The interviewer doesn't care which one you pick as much as whether you can articulate what you're gaining and what you're giving up. See CAP theorem vs PACELC for the foundational framework.

4. Can you communicate while you think? The interview is a collaborative conversation, not a solo whiteboard exercise. You're expected to narrate your reasoning as you design, invite the interviewer's input, and adapt when they push back.

Example walkthrough (abbreviated)

"Design a chat application like WhatsApp."

A strong opening (first 3 minutes): "Before I start designing, let me clarify scope. I'll assume we need: one-to-one messaging, group messaging up to 1,000 members, delivery receipts (sent/delivered/read), online presence indicators, and persistent message history. I'll put voice/video calls, stories, and end-to-end encryption out of scope for now. Sound right?"

Then capacity estimation: "500M DAU, 40 messages per user per day, 20B messages per day, peak 700K messages/second. This is write-heavy and connection-heavy. I'll need WebSockets for persistent connections, Kafka for async message delivery, Cassandra for message storage, and Redis for caching and presence."

Then sketch the architecture, deep-dive on message ordering and delivery guarantees, discuss the fan-out strategy for groups, and handle follow-ups about failure modes.

For the full walkthrough: How to Design a Chat Application.

How to prepare for product design interviews

Practice the top 25 system design interview questions. Every single one is a product design question. Start with the URL shortener (simplest, exercises every concept), then the chat app (introduces real-time), then the news feed (introduces fan-out). After those three, the patterns repeat across every other question.

The concepts you'll use in every product design interview: database sharding, caching, load balancing, message brokers, and consistency models.

Type 2: Infrastructure Design

Infrastructure design interviews ask you to build the platform services that products run on. Instead of designing Instagram, you're designing the distributed cache that Instagram uses, or the message queue, or the monitoring system.

What happens

The question sounds different from product design:

• "Design a distributed key-value store like DynamoDB"
• "Design a rate limiter"
• "Design a job scheduler"
• "Design a distributed cache like Redis"
• "Design a log aggregation system"
• "Design a CDN"

These questions go deeper on distributed systems fundamentals and care less about product-level requirements (there's no "user" to clarify, no "feed" to rank). The depth is in the data structures, the consistency protocols, the failure modes, and the distributed coordination.

How it differs from product design

Three key differences:

1. The problem is more constrained. In product design, you choose what to build (the requirements are ambiguous). In infrastructure design, the requirements are clearer: build a key-value store that supports get/put/delete with configurable consistency. The ambiguity is in the implementation, not the scope.

2. The depth is deeper on a narrower topic. Instead of touching 6-8 concepts lightly (sharding, caching, load balancing, etc.), you'll spend 30 minutes going deep on one or two (consistent hashing, quorum reads, leader election). The interviewer expects you to know the algorithms, not just the concepts.

3. Distributed systems theory matters more. Product design interviews rarely ask about Paxos or vector clocks. Infrastructure design interviews might. You need to understand CAP theorem, consensus protocols, and failure semantics at a deeper level.

Example walkthrough (abbreviated)

"Design a distributed rate limiter."

The opening is tighter than product design (the scope is already clear): "I'll design a rate limiter that enforces per-client request limits across a fleet of API servers. The core requirements: sub-millisecond check latency, distributed-safe (correct across all servers), configurable limits per client and endpoint, and graceful degradation when the rate limiter's backing store is unavailable."

Then the algorithm choice: "I'll use token bucket for the core algorithm because it naturally handles burst traffic. The distributed state lives in Redis, with a Lua script for atomic refill-and-consume operations."

Then the deep dive: how do you handle Redis failures (fail-open vs fail-closed), how do you shard across Redis nodes (consistent hashing by client_id), how do you handle hot keys (write sharding with aggregation on read).

For the full walkthrough: How to Design a Rate Limiter.

How to prepare for infrastructure design interviews

Infrastructure design is less common but more demanding. The preparation path:

1. Study the foundational papers: Dynamo (key-value stores), MapReduce (batch processing), Raft (consensus), Kafka (distributed logs). You don't need to memorize them, but you need to understand the core ideas.
2. Practice: distributed cache, rate limiter, key-value store, job scheduler, CDN design. Each one exercises a different distributed systems concept.
3. Go deeper on: consistent hashing, database replication, leader election, and idempotency.
4. Know the difference between NoSQL database types and when each is the right choice.

Who asks these? Google (especially for infrastructure/platform roles), Amazon (for AWS and core services), and any company building developer tools or cloud infrastructure. If you're interviewing for a backend infrastructure role specifically, expect at least one infrastructure design round.

Type 3: Object-Oriented Design (OOD)

OOD interviews test your ability to model real-world entities as classes, relationships, and interactions. They're less about distributed systems and more about software engineering fundamentals: inheritance, composition, design patterns, SOLID principles, and clean abstractions.

What happens

The question gives you a real-world domain and asks you to design the class hierarchy:

• "Design a parking lot system"
• "Design a chess game"
• "Design a library management system"
• "Design an elevator system"
• "Design an online bookstore"
• "Design a vending machine"

You're expected to identify the entities (ParkingLot, Floor, Spot, Vehicle), define their relationships (a Floor has many Spots, a Spot holds one Vehicle), assign responsibilities (who decides which spot a car goes to?), and apply design patterns where appropriate (Strategy pattern for pricing, Observer pattern for availability notifications).

How it differs from product design and infrastructure design

1. No distributed systems. You're not thinking about sharding, replication, or network partitions. The system runs on one machine (conceptually).

2. The code matters. In product and infrastructure design, you rarely write actual code. In OOD, you're expected to write (or at least sketch) class definitions, method signatures, and key interactions. The interviewer wants to see how you structure code, not just how you draw boxes.

3. SOLID principles and design patterns are explicitly evaluated. Open/closed principle, dependency injection, factory pattern, strategy pattern. If you haven't reviewed these recently, they'll feel rusty. The full treatment: essential software design principles.

4. The system scope is much smaller. A parking lot is not a distributed system. The complexity is in the clean modeling and extensibility, not in the scale.

Example walkthrough (abbreviated)

"Design a parking lot system."

Identify entities: ParkingLot (has floors), Floor (has spots), ParkingSpot (has a type: compact/regular/large and a status: available/occupied), Vehicle (has a type: motorcycle/car/bus), Ticket (records entry time, assigned spot).

Define relationships: ParkingLot contains Floors. Floor contains ParkingSpots. A ParkingSpot can hold one Vehicle. A Ticket references one Vehicle and one ParkingSpot.

Assign behaviors: ParkingLot.findAvailableSpot(vehicleType) scans floors for the nearest available spot matching the vehicle type. ParkingSpot.occupy(vehicle) marks the spot taken and returns a Ticket. ParkingSpot.release() marks the spot available. PricingStrategy.calculate(ticket) computes the fee based on duration and spot type.

Apply patterns: Strategy pattern for PricingStrategy (different pricing for weekdays vs weekends, different tiers). Observer pattern if you want real-time availability updates to a display board.

For the full case study: How to Design a Parking System.

How to prepare for OOD interviews

1. Review SOLID principles and the most common design patterns (Strategy, Observer, Factory, Singleton, Decorator). See OOP for interviews.
2. Practice 5-6 OOD problems: parking lot, chess, elevator, library, vending machine, online bookstore. The patterns repeat.
3. Practice writing class definitions quickly. The interviewer wants to see classes with methods and relationships, not production code.
4. Think about extensibility: "If the parking lot adds EV charging spots tomorrow, does my design handle it without rewriting everything?" This is the SOLID principle in action.

Who asks these? Amazon (Leadership Principle: "invent and simplify" maps naturally to OOD), Microsoft, Bloomberg, and many non-FAANG companies. OOD is declining in frequency at Google and Meta (they prefer product or infrastructure design), but it's alive and well at Amazon and in financial services.

Type 4: Front-end / API Design

API design interviews ask you to design the interface between systems. Not the backend implementation, not the database, not the scaling strategy. The API itself: endpoints, request/response shapes, error handling, authentication, pagination, versioning, and rate limiting.

What happens

The question focuses on the contract:

• "Design the REST API for a payment gateway"
• "Design the API for a social media platform"
• "Design the GraphQL schema for an e-commerce product catalog"
• "Design the API for a calendar application"
• "Design the webhook system for a notification service"

You're expected to define endpoints, HTTP methods, request bodies, response formats, error codes, pagination strategy (cursor vs offset), authentication mechanism (OAuth, API keys), rate limiting headers, and API versioning strategy (URL path vs header).

How it differs from the other three types

1. The focus is on the interface, not the implementation. The interviewer doesn't care how you shard the database behind the API. They care whether your endpoint design is intuitive, consistent, and extensible.

2. REST conventions and HTTP semantics matter a lot. Knowing when to use POST vs PUT vs PATCH, what status codes to return (201 Created, 204 No Content, 409 Conflict, 429 Too Many Requests), how to structure nested resources (/users/{id}/posts vs /posts?user_id={id}), and when to use query parameters vs path parameters.

3. Backward compatibility is a first-class concern. "If we add a new field to the response next month, will existing clients break?" Versioning strategies (URL-based: /v1/users vs /v2/users, header-based: Accept: application/vnd.api+json;version=2) and deprecation policies are fair game.

4. Developer experience is part of the evaluation. The interviewer is asking: "Would a developer who's never seen our API before understand how to use it from the docs alone?" Consistency in naming (plural nouns for collections: /users not /user), predictable patterns (every resource supports GET/POST/PUT/DELETE the same way), and good error messages (specific error codes with human-readable descriptions, not just "400 Bad Request") all contribute.

Example walkthrough (abbreviated)

"Design the REST API for a payment gateway."

Core resources: Payments, Refunds, Customers, PaymentMethods.

Endpoints:

POST   /v1/payments          — Create a new payment (charge a customer)
GET    /v1/payments/{id}     — Retrieve payment details
POST   /v1/payments/{id}/refund  — Refund a payment (partial or full)
POST   /v1/customers         — Create a customer
GET    /v1/customers/{id}    — Retrieve customer details
POST   /v1/customers/{id}/payment-methods  — Add a payment method

Design decisions to discuss:

• Idempotency keys on POST /payments (the client sends a unique key; the server checks for duplicates before processing). See idempotency in system design.
• Async vs sync payment processing. POST /payments returns 202 Accepted with a webhook for the result, or 200 OK with the final status? Trade-off: sync is simpler for the client, async handles slow payment networks better.
• Pagination on list endpoints: cursor-based (stable under concurrent writes) vs offset-based (simpler but breaks when new records are inserted).
• Versioning via URL path (/v1/) because it's the most explicit and debuggable.
• Error format: { "error": { "code": "insufficient_funds", "message": "The card has insufficient funds.", "param": "amount" } } — machine-readable code plus human-readable message.

For the deeper treatment of API design: mastering the API interview and REST vs GraphQL vs gRPC.

How to prepare for API design interviews

1. Study Stripe's API documentation. It's the gold standard for REST API design. Every decision (naming, error format, pagination, idempotency) is excellent and well-documented.
2. Understand the differences between REST, GraphQL, and gRPC and when each is appropriate.
3. Review HTTP semantics: methods, status codes, headers, content negotiation.
4. Practice designing 3-4 APIs: payment gateway, social media platform, e-commerce catalog, calendar. Focus on consistency and developer experience.
5. Read API design best practices and the API design checklist.

Who asks these? Stripe (famously), Twilio, Shopify, Plaid, Square, and any API-first company where the API IS the product. Also increasingly common at FAANG for front-end and full-stack roles where the candidate isn't expected to design backend infrastructure but IS expected to design clean interfaces.

How to figure out which type you'll face

Before your interview, you can usually determine which type to expect:

Ask the recruiter directly. "Will the system design round focus on product design, infrastructure, or OOD?" Most recruiters will tell you. If they say "system design" without qualification, it's almost certainly product design.

Check the role description. Infrastructure/platform roles → infrastructure design. Mobile/frontend roles → API design. Backend generalist roles → product design. Roles that mention "OOP" or "design patterns" → possibly OOD.

Check the company's interview guide. Google, Meta, and Amazon all publish interview prep guides (or have well-known third-party descriptions) that specify the interview round types. The company-specific interview guides on our blog break these down.

Check Glassdoor and Blind. Recent interview reports often specify whether the system design round was "design Twitter" (product) or "design a message queue" (infrastructure) or "design a deck of cards" (OOD).

When in doubt, prepare for product design. It's the most common type by a wide margin. If you're fully prepared for product design, you can handle 70% of the infrastructure questions (the concepts overlap) and you can adapt to OOD with a few days of focused practice on class modeling.

Can you face multiple types in the same interview loop?

Yes. A typical FAANG interview loop has 4-6 rounds, and 1-2 of them are system design. It's common to get one product design round and one that's different. Google sometimes pairs a product design round with an infrastructure design round. Amazon sometimes pairs a product design round with an OOD round.

The good news: the foundational concepts (scalability, databases, caching, trade-offs) apply across all four types. The differences are in framing and depth, not in underlying knowledge.

Putting it all together

The four types aren't four separate worlds. They're four lenses on the same underlying skill: designing software systems that work. Product design is the widest lens (whole systems). Infrastructure design zooms into the platform layer. OOD zooms into the code layer. API design zooms into the interface layer. A senior engineer can operate at all four levels.

For most candidates, the right prep strategy is:

1. Master product design first (it's the most common and the broadest). Start with the complete system design interview guide and the top 25 questions hub.
2. Layer in OOD if interviewing at Amazon or Microsoft — 3-5 days of focused practice on class modeling is enough.
3. Layer in infrastructure design if interviewing for a platform/infra role — study the papers and practice the infra-specific questions.
4. Layer in API design if interviewing at an API-first company — study Stripe's docs, practice 3-4 API designs.

The 7-step framework from the complete guide applies to all four types with minor adjustments. Learn the framework once, adjust the depth per type, and you're covered.

Good luck with your interviews.