System design guide
Meta product architecture vs system design: what's different
Meta's software engineering loop includes one design round, and it comes in two flavours: system design and product architecture (sometimes called product design). Candidates often ask which one they'll get and how to prepare differently. Here's what's publicly known and what it means for your prep.
Meta doesn't publish its interview rubric. This page summarises public candidate reports and prep-site write-ups (sources at the end) plus general design-interview practice. Your recruiter is the authoritative source for your loop.
The two rounds in one table
| System design | Product architecture | |
|---|---|---|
| Typical candidates | Infrastructure, backend, distributed-systems roles | Product engineering roles (full-stack, mobile, product backend) |
| Starting point | Scale, traffic, and system requirements | User journeys and product behaviour |
| Where depth is expected | Storage engines, partitioning, replication, consistency, queues, failure handling | API design, data model, client/server responsibilities, pagination, real-time updates, product edge cases |
| Example prompts (reported) | Distributed cache, metrics/logging pipeline, rate limiter, top-K, web crawler | News feed, Instagram-style photo sharing, comments/likes, chat, event invites |
| Typical length | ~45 minutes | ~45 minutes |
What the product architecture round emphasises
- API design. Expect to define endpoints carefully: resource names, request and response shapes, pagination (cursor-based), idempotency for writes, and error cases. A sloppy API is a common reason candidates underperform here.
- Data model. Entities, relationships, and which queries the product needs. Be ready to explain how a "like" or a "comment count" is stored and kept roughly accurate at scale.
- Client-server interaction. What the client caches, how it gets real-time updates (polling, long polling, WebSockets, push), and how it behaves offline.
- Product behaviour. Privacy rules (who can see a post), ordering and ranking at a high level, notifications, and abuse cases.
- Scale still matters, just less deeply: you should still estimate traffic and know where caching and sharding go.
What the system design round emphasises
- Distributed-systems depth. Partitioning schemes, replication and consistency models, consensus where needed, and what happens when nodes fail.
- Throughput and latency at scale. Back-of-the-envelope estimates that drive concrete decisions about caching layers, batching, and storage choices.
- Data pipelines and infrastructure. Queues, stream processing, aggregation, and back-pressure.
- Operability. Monitoring, deploys, and graceful degradation.
Same prompt, different answer: "Design a news feed"
In product architecture, a strong answer spends real time on the feed API (GET /feed?cursor=, page size, how new posts appear while scrolling), the post and follow data model, how the client shows likes and comments, privacy filtering, and the high-level fan-out choice.
In system design, the same prompt shifts toward the fan-out pipeline, the celebrity problem, feed storage and cache sizing, ranking infrastructure, and failure handling when the fan-out queue lags. The news feed guide covers both halves; choose which sections to go deep on based on your round.
How to prepare for each
Product architecture
- Practise writing complete APIs for five or six consumer products, including pagination and error responses.
- For each, draw the data model and list the top queries.
- Know the real-time options (polling, SSE, WebSockets, push notifications) and when each is appropriate; design a chat app covers the trade-offs.
- Still do quick estimates, so you know when caching and sharding become necessary.
System design
- Work through infrastructure-flavoured prompts: rate limiter, distributed cache, metrics pipeline, web crawler, key-value store.
- Be fluent in consistency models, replication, and partitioning, and be able to explain failure scenarios.
- Practise estimation until it takes under five minutes; see back-of-the-envelope estimation.
For both, use the same skeleton, the 45-minute system design framework, and shift where the deep dive goes.
Sources
- IGotAnOffer, "Meta product architecture interview": igotanoffer.com/en/advice/meta-product-architecture-interview
- Exponent, "Meta system design interview": tryexponent.com/blog/meta-system-design-interview
- Candidate discussion on Blind: teamblind.com
- Design Gurus, "Meta system design vs product design": designgurus.io/blog/meta-system-design-vs-product-design
FAQ
Can I choose between product architecture and system design at Meta?
Candidates report that the round is usually assigned based on the role and team (product-focused vs infrastructure-focused), and some say recruiters let them choose. Ask your recruiter directly; it's a normal question.
Is product architecture easier than system design?
Not easier, differently weighted. You'll still need to discuss scale and storage, but more time goes to APIs, client-server interaction, data models, and product behaviour, and less to distributed-systems internals.
Can the same question appear in both rounds?
Yes. Candidates report prompts like "design a news feed" or "design a video platform" in both. What changes is which parts the interviewer wants you to go deep on.