← Google Interview Insights

Google·Software Engineer·Onsite - System Design / Architecture·Staff

StaffPrefer not to say
Apr 2026

Summary

System design round at Google for an EM role. The question was a full-blown photo/video storage system at Google Photos scale, and it went pretty deep into storage architecture, ML pipelines, and cost tradeoffs. Left feeling like I covered maybe 70% of what they were looking for.

Questions Asked (1)

Q1

Design a photo and video storage service similar to Google Photos that can handle billions of users and hundreds of billions of media files, including upload/download, browsing by date/album/face/location, sharing, and cross-device sync.

System DesignTechnical Trade-offsData Modeling
Author's notes

I started with object storage and a metadata layer which felt right, but I spent way too long on the upload flow and didn't get to the ML feature extraction pipeline until they nudged me.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying functional and non-functional requirements, then estimate scale (billions of users, hundreds of billions of files). Design a high-level architecture covering upload, storage, metadata, indexing, and serving, then dive into key components like media processing, search, and sync, discussing trade-offs and scalability.

Pro tip: Emphasize how you would leverage Google's existing infrastructure (e.g., Colossus, Bigtable, Spanner) and highlight the importance of metadata design and indexing for fast queries at scale.

1. Requirements and Scale Estimation

Clarify functional requirements (upload, download, browse, share, sync) and non-functional (availability, durability, latency). Estimate scale: billions of users, hundreds of billions of files, petabytes of storage, and high read/write throughput.

2. High-Level Architecture

Outline core components: client apps, API gateway, upload service, media processing pipeline, storage layer (blob store + metadata DB), indexing services, and CDN for serving. Ensure separation of concerns and scalability.

3. Data Modeling and Storage

Design metadata schema (e.g., Bigtable/Spanner) for efficient queries by date, album, face, location. Use blob storage (e.g., Colossus) for media files. Discuss sharding, replication, and consistency trade-offs.

4. Media Processing and Indexing

Describe asynchronous processing for thumbnails, transcoding, and ML-based feature extraction (face, object, location). Build inverted indexes for fast search and browsing.

5. Sharing, Sync, and Serving

Design sharing via access control lists and signed URLs. Implement cross-device sync using change logs and push notifications. Serve media via CDN with caching and adaptive streaming.

Key Points to Mention

  • Use of distributed storage systems like Colossus for durability and scalability.
  • Metadata management with Bigtable/Spanner for low-latency queries at scale.
  • Asynchronous processing pipeline for media transcoding and ML feature extraction.
  • Efficient indexing strategies (e.g., inverted indexes, geospatial indexes) for browsing by date, album, face, location.
  • Sharing and access control using ACLs and signed URLs.
  • Cross-device sync via change data capture and push notifications.

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.