The Google FDE Tech Stack
Explore the components and architecture of the Google Forward Deployed Engineer tech stack. Learn to trace requests through authorization, application logic, and data services, and understand how to map each layer's responsibilities in real-world deployments. This lesson illustrates integration with Gemini, LangGraph, BigQuery, and Cloud Run to build secure, manageable applications. Gain skills to identify failure points and justify design decisions for FDE interviews.
A system architecture diagram shows how a customer request passes through authorization, application logic, and supporting services to produce a response. It distinguishes application logic, model inference, data services, compute infrastructure, and identity management, making each component's responsibilities explicit.
In an FDE interview, you should be able to explain the customer's existing architecture, identify potential failure points, and justify technical decisions at the level of detail required for the role.
The stack at a glance
An FDE stack has seven layers. Each layer does one job, and most interview mistakes come from giving a layer a job it doesn’t do, such as expecting a framework to fix permissions.
Layer | Common Choices | Role |
Frontend | React, TypeScript | Capture the question; display the answer |
Application | Python with LangGraph, ADK, or plain control flow | Run the workflow and decide the next step |
Model | Gemini through Gemini Enterprise Agent Platform (formerly Vertex AI) | Interpret requests and draft answers |
Interoperability | MCP, A2A | Connect to tools (MCP) or to other agents (A2A) |
Data | BigQuery, Dataflow, Dataproc, vector stores | Store, refresh, and retrieve data |
Execution | Cloud Run, GKE, Pub/Sub, Cloud SQL | Host code, carry messages, hold app state |
Access | IAM, service accounts | Decide who may perform which operation on which resource |
Read the table as a list of options. A good design uses only the layers its request path needs and explains why each is there.
Map Kestrel’s responsibilities
Consider Kestrel Energy, an energy utility developing an internal assistant to help call-center staff check outage status. Staff use an existing React interface to query outage information for their authorised service regions. A Python backend uses LangGraph to orchestrate requests, Gemini to interpret questions and generate responses, and BigQuery to retrieve curated outage data. An existing Dataflow pipeline processes grid events to update the curated outage dataset.
Map each component to its responsibility and the system boundary it crosses:
Interaction: The React interface accepts staff queries and displays responses, providing the user-facing entry point to the application.
Request handling: The Python backend receives the request and uses verified user context to process it across the browser-to-backend boundary.
Inference: Gemini interprets the user's question and generates response content using the information provided by the application.
Workflow orchestration: LangGraph manages workflow state and determines which application operation to execute next.
Data access: An application adapter queries BigQuery using an authorised workload identity, crossing the boundary between the application principal and the data resource.
Data processing: A separate Dataflow pipeline processes grid events and updates the curated outage dataset.
Hosting: Cloud Run hosts and executes the Python backend service.
Authorisation: IAM controls which cloud resources the application's identity can access. The application separately enforces each staff member's permitted service-region scope.
The architecture diagram should clearly show component responsibilities, data flows and authorisation boundaries. Include only the services relevant to the request and its supporting data pipeline.
Separate context from callers
A Google Cloud project groups resources and defines boundaries for configuration, IAM policies, and service usage. Kestrel's Google Cloud project ID is kestrel-assistant.
A resource is an identifiable object managed by a Google Cloud service. In this example, the Cloud Run service outage-assistant and the BigQuery dataset curated_outages are resources.
A service's location specifies where its resources or workloads operate, using the regions, zones, or other location options supported by that service. Verify the location requirements for Cloud Run, Gemini, BigQuery, and Dataflow separately. Do not assume that one location setting applies to every service.
A principal is an identity, such as a user or service account, that can be granted permissions through IAM. A service account is a Google Cloud ...