Meta product architecture vs system design interview

The two design rounds in Meta's software engineer loop compared: what product architecture asks for (APIs, data model, client and server) against system design (backend scale and failure), which one you get, example prompts for each, and how to prepare.

Reading is half of it. See it used in a real interview.A strong candidate answers Design a News Feed turn by turn, drawing the design as they talk. Free, no sign-up to start.

Watch the walkthrough

Meta's software engineer loop has one kind of round that confuses people more than any other: the design round comes in two flavours, system design and product architecture. Both are 45 minutes, both start from "design X", and the same prompt (a news feed, say) can appear in either. What differs is what the interviewer is listening for. Prepare for the wrong one and you can give a strong answer to a question that was not being asked.

The short version

	Product architecture	System design
The question is about	A user-facing product, end to end	The backend that runs at scale
Typical prompts	Design Instagram Stories, a comment system, Facebook Events, a chat app, a news feed	Design a distributed cache, a metrics pipeline, a top-K service, a key-value store, a news feed
Where the time goes	Requirements from the user's point of view, the API, the data model, how client and server talk	Scale estimates, storage and partitioning, replication, caching, consistency, failure
Depth expected on	Endpoints, payloads, pagination, push vs poll, what the client caches, edge cases in the product	Sharding keys, hot keys, queues, consistency models, what happens when a component dies
Usually given to	Product engineering roles	Infrastructure and backend roles

Public interview guides and candidate reports describe the design round as one or the other, and which one you get follows the role you are interviewing for. If your recruiter has not told you, ask; it is a normal question and they will answer it.

What product architecture is really testing

The question behind product architecture is: can you build a product feature well, from the screen down to the database, so that it is pleasant to use and easy to change? Expect the interviewer to care about:

Requirements as a user sees them. What does the screen show, in what order, what happens on refresh, what about an empty state, deleted content, blocked users?
The API. Endpoints, request and response shapes, pagination (cursor, not offset), idempotency for writes, versioning. This is often the centre of the round, so write it down. See API design and pagination.
The data model. Entities, keys, and which query each screen runs. See data modelling for reads.
Client and server together. What the client caches, how it learns about new content (polling, long polling, server-sent events or a WebSocket), optimistic updates, and offline behaviour on mobile. See real-time systems.
Scale, but not first. Numbers still matter, but the hard part is usually the product logic and the interface, not sharding.

A strong product architecture answer to "design Instagram Stories" spends real time on the upload and viewing APIs, how the tray of stories is built and paginated, how "seen" state is stored, and how stories expire, before it worries about which database holds a billion rows.

What system design is really testing

System design asks whether you can build backend infrastructure that survives scale and failure. The interviewer will push on:

Numbers that drive decisions: requests per second, storage per year, the largest key. See back-of-envelope estimation.
Storage and partitioning: the partition key, hot keys, replication and the consistency it gives. See sharding and partitioning.
Asynchronous work and fan-out: queues, streams, fan-out on write or read.
Failure: what happens when a node, a queue consumer or a region goes away, and how the design recovers.

The same "design a news feed" prompt in a system design round is a conversation about fan-out at a billion users, the celebrity problem, ranking at read time and cache sizing. In product architecture it is a conversation about the feed API, pagination as new posts arrive, how likes and comments update on screen, and the data model for posts.

How to prepare for each

For product architecture: practise writing the API first. For every question you study, write the four or five endpoints with their request and response bodies, choose the pagination, and say how the client finds out about changes. Questions that reward this are the news feed, Instagram, Slack, Yelp and Reddit. Spend less time on consensus and storage engines.

For system design: practise the scale story. Questions like the distributed cache, the key-value store, the message queue, metrics and monitoring and the rate limiter make you defend partitioning, replication and failure handling.

For both: the structure of the hour is the same. Agree the requirements, put numbers on them, sketch the API and data model, draw the high-level design, then go deep where it is hard. The interview framework covers that structure, and what interviewers expect at each level covers how the bar moves from mid-level to staff.

Common mistakes

Answering a product architecture question with infrastructure. Twenty minutes on Cassandra partitioning while the API is still undefined reads as not having understood the round.
Answering a system design question with screens. Spending the first half on UI states and endpoint names leaves no time for the scale and failure questions that decide it.
Treating the API as a formality. In product architecture it is often the most graded part. Name the fields, the cursor, the error cases.
Skipping numbers in product architecture. Less weight is not no weight. A feed that must serve 2 billion users still needs a sentence on what that implies.

Questions people ask

What is the Meta product architecture interview?

It is one of the two forms of the design round in Meta's software engineer loop. You design a user-facing product end to end: requirements from the user's point of view, the API with request and response shapes and pagination, the data model, and how client and server talk, including push or poll and what the client caches. Scale still matters, but the product logic and the interface are the centre of the round.

What is the difference between product architecture and system design at Meta?

Both are 45-minute design rounds that start from "design X", but they listen for different things. Product architecture is about building a user-facing product well: the API, the data model and the client-server interaction. System design is about backend infrastructure at scale: estimates, storage and partitioning, replication, caching, consistency and failure. The same prompt, such as a news feed, can appear in either with a different emphasis.

Do I get product architecture or system design at Meta?

It follows the role you are interviewing for: product engineering roles usually get product architecture, and infrastructure and backend roles get system design. If your recruiter has not told you which one you will have, ask them; it is a normal question and they will answer it.

What questions are asked in a Meta product architecture interview?

Typical prompts are user-facing products: Instagram Stories, a comment system, Facebook Events, a chat app or a news feed. A strong answer spends real time on the API, pagination, the data model and how the client learns about new content, before worrying about which database holds a billion rows.

How should I prepare for a product architecture interview?

Practise writing the API first. For every question you study, write the four or five endpoints with their request and response bodies, choose the pagination, and say how the client finds out about changes. Questions such as a news feed, Instagram, Slack, Yelp and Reddit reward this. Spend less time on consensus and storage engines than you would for a system design round.