Gemini request path: architecture from user prompt to grounded, streamed answer

Quick Overview

A Google product manager system design prompt about how Gemini turns a user's query into a streamed answer. It tests whether the candidate can lay out the request path, grounding with search and tools, model serving, safety checks, latency and cost trade-offs, and the metrics that show the assistant is working well.

Gemini request path: architecture from user prompt to grounded, streamed answer

Company: Google

Role: Product Manager

Category: System Design

Difficulty: medium

Interview Round: Other

At a high level, design the system that lets Gemini answer a query a user sends it: the main components and how one request moves through them. ```hint Follow one request Trace a single query from the moment the user presses send until the last words appear. Ask what has to happen before the model runs, while it generates, and after it finishes, and which of those steps drive latency and cost. ``` ### Clarifying Questions - Which surface is in scope: the consumer Gemini app on web and mobile, or the developer API that other products build on? - Are only text queries in scope, or also images, uploaded files and voice? - Should questions about fresh facts, such as news or sports scores, be grounded in live search results, or may the model answer from what it learned in training? - Are multi-turn conversations and actions in a user's connected apps, such as email or calendar, part of the first version? ### What a Strong Answer Covers - A request path from client to response that names the steps before, around and after model inference: conversation context, safety checks, retrieval and tools, the model, and post-processing. - How the system decides when to ground an answer in search results or call a tool, and how sources reach the user. - Latency and cost levers for serving a large model to many users: streaming, routing between model sizes, batching and caching, capacity across regions. - Safety, privacy and failure handling: input and output checks, behavior when a dependency is slow or down, and what happens to user data. - Metrics and feedback loops that show whether answers are helpful, fast and safe. ### Follow-up Questions - A launch doubles peak traffic and accelerator capacity runs out. What do you degrade first, and what would users notice? - How would the system decide whether a query goes to a smaller, faster model or the largest one? - A grounded answer cites a page that does not support its claim. Where in the system would you catch that, and how would you measure how often it happens?

Overview: A Google product manager system design prompt about how Gemini turns a user's query into a streamed answer. It tests whether the candidate can lay out the request path, grounding with search and tools, model serving, safety checks, latency and cost trade-offs, and the metrics that show the assistant is working well.

Google logo
Google
Jun 28, 2026
mediumProduct ManagerOtherSystem Design
0
0

At a high level, design the system that lets Gemini answer a query a user sends it: the main components and how one request moves through them.

Clarifying Questions Guidance

  • Which surface is in scope: the consumer Gemini app on web and mobile, or the developer API that other products build on?
  • Are only text queries in scope, or also images, uploaded files and voice?
  • Should questions about fresh facts, such as news or sports scores, be grounded in live search results, or may the model answer from what it learned in training?
  • Are multi-turn conversations and actions in a user's connected apps, such as email or calendar, part of the first version?

What a Strong Answer Covers Guidance

  • A request path from client to response that names the steps before, around and after model inference: conversation context, safety checks, retrieval and tools, the model, and post-processing.
  • How the system decides when to ground an answer in search results or call a tool, and how sources reach the user.
  • Latency and cost levers for serving a large model to many users: streaming, routing between model sizes, batching and caching, capacity across regions.
  • Safety, privacy and failure handling: input and output checks, behavior when a dependency is slow or down, and what happens to user data.
  • Metrics and feedback loops that show whether answers are helpful, fast and safe.

Follow-up Questions Guidance

  • A launch doubles peak traffic and accelerator capacity runs out. What do you degrade first, and what would users notice?
  • How would the system decide whether a query goes to a smaller, faster model or the largest one?
  • A grounded answer cites a page that does not support its claim. Where in the system would you catch that, and how would you measure how often it happens?