System Design for PMs
System design questions never disappeared. They got quieter recently, pushed aside by the wave of AI-related technical questions. But companies like Amazon, Stripe, Uber, and Roblox still run them.
This level of detail is generally sufficient for PMs. If you want to go deeper on any of the concepts, check out our system design course.
Why this matters now
The assumption that system design is an engineering concern has always been wrong, but it now costs more. PMs are taking on more ownership of technical decisions: scoping features against infra constraints, pushing back on complexity estimates, and making build-vs-buy calls without engineering in the room. Interviewers use system design questions to test exactly that capacity.
The bar isn't engineering depth; it’s product judgment applied to technical constraints. Those are different things, and this lesson shows you how to demonstrate the latter without needing to have the former.
Some companies have shifted toward AI-specific system design questions. Google, for example, has asked candidates to design a high-level system for Gemini, responding to a user query. This lesson focuses on traditional system design. The AI Technical Fluency lesson covers AI-specific questions separately.
What interviewers are scoring
Your recruiter will flag in advance if a system design round is in your loop. When it appears, the interviewer is not checking for code, implementation details, or infrastructure expertise. They're scoring four things:
- Whether you can translate user needs into system requirements
- Whether you can identify the components that matter and explain why they're there
- Whether you reason about tradeoffs before being asked
- Whether you're credible enough on technical constraints to be a real partner to engineering
System design in a PM loop is fundamentally a scoping exercise dressed as a technical one. The interviewer wants to see how you decide what matters, not how deep you know a particular component.
The five-step framework
These steps work for almost any system design prompt. The order is deliberate: each step builds the foundation for the next. The most common failure mode is skipping straight from prompt to architecture and spending ten minutes designing the wrong system.
We'll walk through each step using a real, recent question from a Roblox PM loop.
The prompt:
Roblox has users in different languages and a machine learning system for auto-translation. Design a system that would automatically translate between different people on different servers.
This is a real question from a Roblox APM loop. A candidate who went through this process noted that "the product and system questions both kept tying back to the Roblox ecosystem instead of feeling like generic PM cases", meaning that the answer had to be grounded Roblox-specific context. Knowing what the platform does (real-time multiplayer, young audience, creator economy) changes what requirements you surface in Step 2.
Step 1: Clarify and scope
This is the step most candidates rush, and it's where interviews are lost.
Before drawing anything, ask questions. Who are the users and what are they trying to accomplish? Are there constraints worth knowing about: scale, latency requirements, data sensitivity? What functionality should be in scope, and what should be explicitly excluded?
Even if the prompt seems unambiguous, summarizing your understanding back to the interviewer before you start serves two purposes: it signals that you think before you build, and it gives the interviewer a chance to course-correct before you're ten minutes in.
Good clarifying questions here:
- "Does translation need to happen in real time during live gameplay, or is some delay acceptable?"
- "Are we translating chat messages only, or also in-game text like item names and UI elements?"
- "Should the system support all Roblox languages or a prioritized subset?"
These questions change the architecture significantly. Real-time chat translation in a live game is a very different system from batch translation of UI text. Establish this before you draw anything.
Step 2: Define requirements from user needs
Now you translate your product understanding into concrete requirements in the form of a user journey: walk through what the user does step by step, then convert each step into a system requirement.
This step comes before architecture for a specific reason: requirements give you a principled basis for deciding which components belong in your diagram. If a component doesn't trace back to a requirement, it probably shouldn't be there. Candidates who skip this step almost always over-engineer or miss something obvious.
Simple user journey:
- Player A (Portuguese speaker) types a message in a shared game chat
- Player B (English speaker) is in the same session
- Player B should see a translated version of that message in near-real time
From that journey, four requirements emerge:
- The system detects the source language of each incoming message
- The system translates the message into the recipient's preferred language
- Translation happens fast enough to feel real-time in a gameplay context (under ~300ms)
- User language preferences are stored and retrievable
Step 3: Identify system attributes
Beyond what the system does, define how it should feel. These are qualities, not features. Common attributes in PM loops: speed, accuracy, reliability, privacy/security.
This step comes before architecture because your attributes determine your tradeoffs. Two systems with identical requirements but different attributes can look completely different in practice. A medical records system and a social feed technically have similar data requirements. Their attributes make them architecturally different products.
"Given the gameplay context, speed is the priority. A translated message that arrives three seconds late has lost all conversational meaning. Accuracy matters, but imperfect translation is preferable to no translation. Players are used to imperfect cross-language communication. Privacy is also relevant because chat content is user-generated and potentially sensitive, especially on a platform with a young user base."
Step 4: Build the basic architecture
Now draw the diagram. Cover every component needed to satisfy your requirements, what each component does, and how components communicate with each other.
Stay at the right altitude. You're not writing pseudocode or specifying a schema. You're showing that you understand the pieces, why they're each there, and how data flows between them.
At a high level:
- The game client sends a chat message to the API gateway
- The gateway routes the request to the translation service
- The translation service checks a language cache. Has this phrase been translated before? If yes, serve from cache immediately
- On a cache miss: call a language detection module to identify the source language, then pass the message to the ML translation model
- The translation result is stored in cache for future use
- The translation service fetches the recipient's preferred language from the user preferences database
- The translated message is returned to the game client
Step 5: Surface tradeoffs and improvements
Close by proactively raising the tensions in your design. Don't wait to be asked. This is the step where senior candidates set themselves apart. Not because they built a perfect system, but because they already know where it bends.
Ask yourself: what in this architecture is at odds with the attributes I defined? What are the failure modes? What would I change if scale doubled or latency requirements tightened?
Candidates who only describe what they built look like they're presenting. Candidates who also say, "Here's what I'd worry about and why," look like they're thinking.
"A few tensions worth flagging. Chat is colloquial. Players use slang and game-specific shorthand that doesn't cache well, so cache hit rates will be lower than expected, and the ML model will be called frequently. We need fallback behavior: show the original message while translation loads rather than blocking the conversation. And if Roblox is using a third-party translation API, there are two concerns: cost at scale and data privacy for user-generated content on a platform with a young audience. Those are conscious tradeoffs, not flaws."
Reported from this Roblox loop noted that interviewers wanted "both high-level product thinking and some technical/system thinking, different interviewers seem to want different levels of detail." Anchor in the product layer, but be ready to go deeper on any component when pushed.
A solid answer identifies one or two tradeoffs when prompted and explains them clearly, connecting them to user impact.
A senior+ answer surfaces tradeoffs before being asked, connects them explicitly back to the system attributes defined in step three, and closes with a recommendation rather than a list of options. It also raises the second-order concern (e.g., not just "the cache can be stale" but what stale data means for a user mid-game, and the specific mitigation for it).
Variation: Reverse system design
Many companies, such as Stripe, can put you through a reverse system design round (Stripe staff PM interview). The prompt is simply: "Walk me through a system you've previously designed. Describe the architecture, components, and how data flows through it."
They're testing whether you've actually shipped something technical and can articulate it precisely. You have to know the architecture, the data flow, the key tradeoffs, and one concrete technical decision you'd make differently in hindsight. A candidate who recently went through this question puts it plainly: "Go in with one system you know cold and be ready to whiteboard the architecture, the data flow, and one concrete technical tradeoff like conflict handling."
If you've led a technically complex product, this is your moment. If your background is lighter on technical ownership, use prep time to pick the most technical project you've touched and reconstruct it at this level of detail.
Common pitfalls
Don't try to be an engineer. The moment you start speculating about infrastructure tools or implementation details you're not confident about, you lose credibility. Stay at the product-architecture level. If the interviewer wants more depth, they'll push.
Don’t get intimidated by the prompts. If they just say “Design ChatGPT,” and give zero guidance, they are trying to scare you. You don’t need to build something as complex as ChatGPT. That took many people months. You need to buckle down, like you have 45 minutes and a team of engineers for whom you are the tech lead, and you need to come up with a plan for them to build an MVP. It doesn’t have to be fancy. It doesn’t have to be complicated. It just has to get done.
It’s more important to cut scope than it is to add functionality. The more senior a candidate, the more scope they will cut. They will abstract away components: “Let’s keep that as a black box for now, and we can come back to it later.” This is an excellent tactic. You have 45 minutes. Make the scope manageable.
Don’t name a specific brand of technology unless you know its alternatives. Don’t say “Let’s use Redis here” unless you’re ready to answer “Why not Memcached?” If you throw out a brand name, that is the most common follow-up. To be safer, simply say “Let's use a cache here.”
Don't skimp on questions, even if the prompt seems clear. Good system design interviewers purposefully withhold information. And candidates can only unlock that by asking questions. Many times, system design prompts have a linchpin, and the only way to crack it is to ask questions. Requirements gathering unlocks good designs that your interviewer actually wants. Ask away.