Cloud Cheat Sheet · GCP vs AWS
Hoja de referencia rápida para usar durante tu entrevista. Optimizada para Google: GCP primero, servicios "Google-native" destacados con ★, framework estructurado y números pre-computados. Presiona / para buscar cualquier cosa.
1 Framework de la entrevista
Sigue estos 7 pasos en orden. Pierde 2 min y verbalizando cada uno: muestra estructura.
PASO 1
Clarificar
~5 min
Funcionales, no funcionales (latencia, consistencia, disponibilidad), usuarios, alcance.
PASO 2
Estimar
~5 min
DAU, QPS read/write, storage, bandwidth. Razona en voz alta con números redondos.
PASO 3
API Design
~5 min
REST/gRPC. Endpoints, params, response. Esquema de datos básico.
PASO 4
High-Level
~10 min
Diagrama: client → LB → API → service → DB. Cache, queue, CDN si aplica.
PASO 5
Deep Dive
~10 min
El entrevistador elige un componente. Sharding, replicación, índices, consistencia.
PASO 6
Bottlenecks
~5 min
¿Qué falla primero? SPOF, hot partitions, thundering herd. Plan B.
PASO 7
Wrap Up
~5 min
Monitoring, observability, security, futuras extensiones.
❓ Preguntas que SIEMPRE haces
- ¿Cuántos usuarios activos diarios?
- ¿Read-heavy o write-heavy?
- ¿Latencia aceptable? (p50/p99)
- ¿Consistencia fuerte o eventual?
- ¿Global o regional?
- ¿Tamaño promedio del payload?
🎯 Frase de oro al iniciar
"Primero voy a clarificar requisitos y estimar escala, luego diseñar el API y la arquitectura de alto nivel. Después profundizo donde quieras. Voy a separar compute, storage, database y messaging para que escalen independientemente."
⚠️ Errores comunes
- Saltar a la solución sin clarificar
- Mencionar servicios sin justificar
- No estimar números reales
- Diseñar para 1B usuarios desde el inicio
- Olvidar monitoring y failure modes
- No mencionar trade-offs
2 Estimación de capacidad
Números que debes tener pre-computados. Redondea siempre. Verbaliza tus cálculos.
Segundos por día
86,400
≈ 100K (úsalo para QPS rápido)
Segundos por mes
2.5M
30 días × 86,400
Segundos por año
~30M
365 × 86,400 ≈ 31.5M
QPS · 1M req/día
~12
1M / 86,400
QPS · 100M req/día
~1,200
Pico ≈ 2-3x avg
QPS · 1B req/día
~12,000
Pico ≈ 30K QPS
Read:Write social
100 : 1
Twitter/IG approx
Read:Write commerce
10 : 1
Amazon-style
💾 Tamaños de referencia
- Char ASCII: 1 byte
- Char UTF-8: 1-4 bytes
- UUID: 16 bytes (36 chars string)
- Timestamp: 8 bytes (int64)
- Tweet/post: ~1 KB
- Imagen JPEG: ~200 KB - 2 MB
- Video 1 min HD: ~50 MB
- Página web promedio: ~2 MB
📐 Plantilla de cálculo
- QPS = DAU × actions/user / 86,400
- Pico QPS ≈ avg × 2-3
- Storage/día = QPS × payload × 86,400
- Storage 5 años = storage/día × 1,825
- Bandwidth = QPS × payload (bits)
- Cache size = 20% del hot data (regla 80/20)
- Replicas = redundancia × 3 (típico)
"Para 100M DAU con 10 acciones diarias: 1B requests/día → ~12K QPS promedio, ~30K QPS pico. Si cada request escribe 1KB, son 1TB/día, 365TB/año. Necesito sharding desde el inicio."
3 Latency numbers (Jeff Dean)
Clásico de Google. Si te preguntan cualquier cosa de latencia, estos son los números.
| Operación | Latencia | Comparación mental |
|---|---|---|
| L1 cache reference | 0.5 ns | Base · 1 ciclo de CPU moderna |
| Branch mispredict | 5 ns | 10× L1 |
| L2 cache reference | 7 ns | 14× L1 |
| Mutex lock/unlock | 25 ns | 50× L1 |
| Main memory reference (RAM) | 100 ns | 200× L1 · 20× L2 |
| Compress 1KB con Zippy/Snappy | 3 μs | 30,000× L1 |
| Send 1KB sobre red 1 Gbps | 10 μs | 100,000× L1 |
| Read 1MB secuencial de RAM | 250 μs | 2.5M× L1 |
| Round trip mismo datacenter | 500 μs (0.5 ms) | El "barómetro" del datacenter |
| Read 1MB secuencial de SSD | 1 ms | 4× faster than disk |
| Disk seek (HDD) | 10 ms | 20× round trip · ¡Evítalo! |
| Read 1MB secuencial de disk (HDD) | 30 ms | 120× SSD |
| Round trip CA → Netherlands → CA | 150 ms | 300× datacenter · CDN! |
⚡ Targets típicos
- API p50: < 100ms
- API p99: < 500ms
- Page load: < 2s
- Search autocomplete: < 50ms
- Video start: < 2s
🌐 Memoria vs disco vs red
Si RAM = 1 segundo, entonces:
SSD ≈ 10 segundos
HDD seek ≈ 100 segundos
Datacenter RTT ≈ 5 segundos
Cross-continent ≈ 25 minutos
📊 Throughput SSD vs HDD
- HDD: ~100 MB/s seq, ~100 IOPS random
- SSD: ~500 MB/s seq, ~10K IOPS
- NVMe: ~3 GB/s seq, ~500K IOPS
- RAM: ~10 GB/s
4 Bases de datos · decisión rápida
SQL, NoSQL, CAP. La pregunta no es "cuál es mejor", es "cuál encaja con mis requisitos".
| Tipo | Cuándo usar | GCP | AWS | CAP / Notas |
|---|---|---|---|---|
| SQL | Transacciones ACID, joins, schema fijo, relaciones complejas. Pagos, ledger, inventario. | Cloud SQL (Postgres/MySQL) | RDS | CP Vertical scale primero |
| SQL global | Consistencia fuerte + escala horizontal + global. Inventario multi-región, finanzas globales. | Cloud Spanner | Aurora Global | CP+HA TrueTime · Único en el mercado |
| Document | Schema flexible, datos anidados, mobile/web apps, real-time sync. | Firestore | DynamoDB | AP Strong opcional |
| Key-Value | Lookups simples por key, alta escritura, baja latencia. Sesiones, carrito, perfiles. | Firestore / Memorystore | DynamoDB | AP O(1) lookup |
| Wide-column | Volúmenes masivos (PB), time series, IoT, métricas, logs, ad analytics. Writes muy altos. | Bigtable | Keyspaces | CP Mismo motor que Gmail/Maps/Search |
| Graph | Relaciones complejas: redes sociales, fraude, recomendaciones, knowledge graph. | Spanner Graph / Neo4j en VM | Neptune | CP Cypher / Gremlin |
| Search | Full-text search, facets, autocompletado, ranking. Catálogos, logs analytics. | Elasticsearch en GKE | OpenSearch | AP Inverted index |
| Cache | Reducir lecturas repetidas a la DB, sesiones, rate limiting, leaderboards. | Memorystore (Redis/Memcached) | ElastiCache | AP En memoria · TTL |
| Warehouse | Analítica SQL sobre PB de datos. Reportes, BI, ad-hoc queries históricas. | BigQuery | Redshift | OLAP Serverless · Columnar |
| Object | Archivos grandes inmutables: imágenes, videos, backups, data lake. | Cloud Storage | S3 | AP 11 nines durabilidad |
🎯 CAP Theorem (en 30 seg)
En presencia de partición de red, eliges entre consistencia o disponibilidad.
- CP Spanner, Bigtable, HBase, Mongo
- AP Cassandra, Dynamo, Couchbase
- Spanner: CP pero con 99.999% (TrueTime)
📚 ACID vs BASE
- ACID: Atomicity, Consistency, Isolation, Durability. SQL clásico.
- BASE: Basically Available, Soft state, Eventually consistent. NoSQL.
- Trade-off: ACID = correctness, BASE = scale.
🇬🇴 Tip Google-specific
A Google le encanta cuando mencionas Spanner (lo inventaron), Bigtable (lo inventaron), BigQuery (Dremel paper). Si encajan con el problema, úsalos. Justifica con TrueTime, escala global, o columnar storage.
5 Patrones comunes
Lo que el entrevistador espera que menciones cuando hay escala, picos, o consistencia.
🚦 Rate Limiting
- Token bucket: permite bursts, refill constante. Default.
- Leaky bucket: tasa fija, suaviza. Para protección.
- Fixed window: simple, pero pico al borde.
- Sliding window: preciso, más memoria.
- Distribuido: Redis con INCR + TTL atómico.
🔪 Sharding / Partitioning
- Hash: uniforme, pero re-shard duele.
- Consistent hashing: minimiza movimiento al re-shard.
- Range: queries por rango eficientes; hot spots si skewed.
- Geographic: latencia baja, regulación.
- Hot partition: evita con salt en el key.
📚 Replicación
- Leader-Follower: writes a leader, reads de followers. Lag eventual.
- Multi-leader: writes en cualquier región. Conflictos.
- Leaderless (Dynamo): quorum R+W>N para consistencia.
- Sync vs async: trade-off latencia vs durabilidad.
🧊 Caching
- Cache-aside (lazy): app lee cache, si miss → DB → escribe cache.
- Write-through: escribe a cache y DB juntos.
- Write-back: escribe a cache, async a DB. Riesgo de pérdida.
- Eviction: LRU, LFU, TTL.
- Stampede: mutex, jittered TTL, request coalescing.
⚖️ Load Balancing
- L4 (TCP): rápido, sin contexto de app.
- L7 (HTTP): routing por path/header, slower.
- Round robin / least conn / IP hash.
- Health checks + circuit breaker.
- GCP: Cloud Load Balancing (anycast global).
📨 Queue vs Pub/Sub
- Queue (SQS): 1 mensaje → 1 consumidor. Trabajo distribuido.
- Pub/Sub (GCP): 1 mensaje → N consumidores. Fan-out de eventos.
- Pub/Sub de Google hace ambos. AWS los separa (SQS+SNS).
- Idempotencia: los consumidores deben tolerar duplicados.
💥 Resilience patterns
- Retry con exponential backoff + jitter
- Circuit breaker: abre tras N fallos, evita cascada.
- Bulkhead: aísla recursos por consumidor.
- Timeout en cada llamada de red.
- Idempotency keys para writes.
🔐 Consistencia
- Strong: read ve último write (Spanner).
- Eventual: converge eventualmente (DNS, Dynamo).
- Read-your-writes: tu propio write es visible.
- Causal: orden causal preservado.
- Linearizability > serializability > causal > eventual.
🆔 ID generation
- UUID v4: 128 bits, sin coordinación, no ordenable.
- ULID / KSUID: ordenables por tiempo.
- Snowflake (Twitter): 64 bits, time + machine + seq.
- Auto-increment: SPOF, no escala global.
6 Equivalencias GCP ↔ AWS
★ = servicio donde GCP es referencia/líder. Menciónalo si encaja con el problema.
Compute & Containers
| Necesidad | Uso en system design | GCP | AWS |
|---|---|---|---|
| Virtual machines | Servidores tradicionales, lift-and-shift, control total. | Compute Engine | EC2 |
| Containers serverless | Microservicios HTTP sin gestionar infra. Scale to zero. | Cloud Run | ECS Fargate / App Runner |
| Kubernetes | Orquestar muchos microservicios, control granular. | GKE | EKS |
| Serverless functions | Código por eventos: triggers de storage, queue, HTTP. | Cloud Functions | Lambda |
| Batch jobs | Procesamiento pesado offline, ML training, ETL. | Cloud Batch / Dataflow | AWS Batch |
Storage
| Necesidad | Uso en system design | GCP | AWS |
|---|---|---|---|
| Object storage | Archivos grandes inmutables: imágenes, videos, backups, data lake. 11 nines durabilidad. | Cloud Storage | S3 |
| Block storage | Disco persistente para una VM. Bases de datos auto-administradas. | Persistent Disk / Hyperdisk | EBS |
| File storage (NFS) | File system compartido entre múltiples VMs. | Filestore | EFS |
| Archive / cold | Datos accedidos raramente, compliance, backups largos. | Cloud Storage Archive | S3 Glacier |
Databases (resumen) — para el detalle ver sección 4
| Necesidad | Uso en system design | GCP | AWS |
|---|---|---|---|
| SQL administrado | ACID, joins, transacciones. Default para datos relacionales. | Cloud SQL | RDS |
| SQL global / fuerte | Consistencia fuerte + escala horizontal + global. Único Spanner. | Cloud Spanner | Aurora Global |
| NoSQL document | Schema flexible, real-time sync, mobile. | Firestore | DynamoDB |
| Wide-column | PB de time series, IoT, ad analytics. Writes muy altos. | Bigtable | Keyspaces |
| Cache | Reducir latencia, sesiones, leaderboards. | Memorystore | ElastiCache |
| Data warehouse | Analytics serverless sobre PB. SQL. | BigQuery | Redshift |
| Data lake | Datos crudos para ML, analytics, auditoría. | Cloud Storage + Dataplex | S3 + Lake Formation |
Networking & CDN
| Necesidad | Uso en system design | GCP | AWS |
|---|---|---|---|
| Load balancer | Distribuir tráfico. GCP es anycast global con una sola IP. | Cloud Load Balancing | Elastic Load Balancing |
| CDN | Servir contenido estático cerca del usuario, reducir latencia y costo. | Cloud CDN | CloudFront |
| DNS | Resolver dominios, geo-routing, health checks. | Cloud DNS | Route 53 |
| Red privada | Aislar servicios, subredes, firewalls, peering. | VPC | VPC |
| API Gateway | Exponer APIs, autenticación, rate limiting, routing. | API Gateway / Apigee | API Gateway |
| Service mesh | Comunicación segura y observable entre microservicios. | Anthos Service Mesh / Istio | App Mesh |
Messaging & Streaming
| Necesidad | Uso en system design | GCP | AWS |
|---|---|---|---|
| Queue (work) | Desacoplar servicios, absorber picos, retry asíncrono. | Pub/Sub | SQS |
| Pub/Sub (events) | Fan-out de eventos a múltiples consumidores. | Pub/Sub | SNS |
| Streaming (Kafka-like) | Procesar eventos en orden, replay, time-windows. | Pub/Sub + Dataflow | Kinesis / MSK |
| Workflow orchestration | Coordinar procesos largos con pasos, retries y compensación. | Workflows | Step Functions |
| Stream processing | ETL en tiempo real, ventanas, agregaciones. | Dataflow (Apache Beam) | Kinesis Data Analytics |
Security · Identity · Secrets · Encryption
| Necesidad | Uso en system design | GCP | AWS |
|---|---|---|---|
| IAM | Roles, permisos, principals, least privilege. | IAM | IAM |
| Secrets | Passwords, tokens, API keys, rotación automática. | Secret Manager | Secrets Manager |
| KMS | Llaves de cifrado, encryption at rest/in transit. | Cloud KMS | KMS |
| WAF / DDoS | Protección ante ataques L7, OWASP top 10, DDoS. | Cloud Armor | AWS WAF + Shield |
| Identity (users) | Autenticación de usuarios finales: OAuth, OIDC, social login. | Identity Platform / Firebase Auth | Cognito |
| Zero trust | Acceso a apps internas sin VPN. | BeyondCorp / IAP | Verified Access |
Observability · Logs · Metrics · Tracing
| Necesidad | Uso en system design | GCP | AWS |
|---|---|---|---|
| Logs centralizados | Búsqueda, alertas, audit, debugging. | Cloud Logging | CloudWatch Logs |
| Métricas / dashboards | SLI/SLO, error rate, latencia p99, saturación. | Cloud Monitoring | CloudWatch Metrics |
| Distributed tracing | Seguir requests entre microservicios, encontrar cuellos. | Cloud Trace | X-Ray |
| Profiling continuo | CPU/heap profiling en producción, encontrar hot code. | Cloud Profiler | CodeGuru Profiler |
| Error reporting | Agrupar y priorizar errores en producción. | Error Reporting | CloudWatch + custom |
DevOps · CI/CD · ML
| Necesidad | Uso en system design | GCP | AWS |
|---|---|---|---|
| CI/CD | Build, test, deploy automatizado. | Cloud Build / Cloud Deploy | CodeBuild / CodePipeline |
| Container registry | Imágenes Docker, vulnerability scanning. | Artifact Registry | ECR |
| ML platform | Entrenar, desplegar y monitorear modelos. | Vertex AI | SageMaker |
| LLMs / GenAI | Modelos generativos, embeddings, RAG. | Vertex AI · Gemini | Bedrock |
| Vector DB | Búsqueda semántica, RAG, recomendaciones. | Vertex AI Vector Search | OpenSearch / Aurora pgvector |
7 Arquitecturas de ejemplo
Plantillas que puedes adaptar a la pregunta que te toque.
📄 API de documentos (Drive-like)
- API pública: Cloud Load Balancing → API Gateway / Apigee
- Backend: Cloud Run o GKE (stateless)
- Metadata: Cloud SQL (relacional) o Firestore
- Contenido: Cloud Storage (signed URLs)
- Cache: Memorystore Redis
- Async: Pub/Sub → Cloud Functions (thumbnails, OCR, indexar)
- Search: Elasticsearch en GKE o Vertex AI Search
- Observability: Cloud Logging + Monitoring + Trace
📺 Video streaming (YouTube-like)
- Upload: Cloud Storage (resumable uploads)
- Transcoding: Pub/Sub → Cloud Run / Transcoder API
- Storage final: Cloud Storage multi-bitrate (HLS/DASH)
- Metadata: Spanner (global) o Bigtable (analytics)
- CDN: Cloud CDN para playback
- Recommendations: Vertex AI + BigQuery (watch history)
- Comments: Firestore o Spanner
- Analytics: Pub/Sub → Dataflow → BigQuery
💬 Chat (WhatsApp-like)
- Conexión: WebSocket en GKE (sticky LB)
- Mensajes: Bigtable (wide-column, time-ordered)
- Presencia: Memorystore Redis (TTL corto)
- Push: Pub/Sub → FCM
- Media: Cloud Storage + signed URLs
- E2E encryption: claves en cliente, servidor solo enruta
- Group fan-out: async vía Pub/Sub
🔗 URL Shortener (bit.ly)
- API: Cloud Run + Cloud Load Balancing
- Generación ID: base62 de counter (Spanner) o hash + colisión-check
- Storage: Bigtable (key=short_url, value=long_url) o Spanner
- Cache: Memorystore Redis (read-heavy)
- CDN: Cloud CDN para redirects populares
- Analytics: Pub/Sub → BigQuery (clicks, geo)
- Rate limit: Cloud Armor + Redis token bucket
🐦 Timeline (Twitter-like)
- Tweets: Spanner (global) + Cloud Storage (media)
- Fan-out on write: Pub/Sub al timeline de followers (Bigtable)
- Fan-out on read: celebrities con >1M followers
- Híbrido: push para usuarios normales, pull para celebrities
- Cache: Memorystore Redis (timelines hot)
- Search: Elasticsearch / Vertex AI Search
- Trending: Dataflow + Bigtable counters
🌐 Web Crawler / Search
- URL frontier: Pub/Sub con prioridad
- Crawler workers: GKE pool autoescalado
- Dedup: Bloom filter + Bigtable seen-URLs
- HTML store: Cloud Storage
- Index: Bigtable (inverted index) o Elasticsearch
- robots.txt cache: Memorystore
- Politeness: token bucket por dominio
"Para documentos grandes, no guardo el contenido en la DB. Metadata en Spanner o Firestore, archivo en Cloud Storage con signed URLs. Tareas pesadas (indexar, OCR, thumbnails) van por Pub/Sub a workers asíncronos. Esto desacopla la API del procesamiento y permite escalar cada pieza independientemente."
8 Preguntas típicas de Google
Las que aparecen una y otra vez. Con la pista de qué quieren ver.
| Pregunta | Conceptos clave | Trampas / lo que buscan |
|---|---|---|
| Diseñar Google Drive / Dropbox | Object storage, metadata DB, signed URLs, sync, deduplicación por hash, chunking | Conflictos de sync (vector clocks), dedup chunk-level, resumable uploads |
| Diseñar YouTube | Upload, transcoding pipeline, CDN, multi-bitrate, recomendaciones, watch history | Cómo manejar 500+ horas/min de upload, hot videos en CDN, viewer count en tiempo real |
| Diseñar Google Maps | Geo-indexing (geohash, S2, quadtree), tile serving, routing, real-time traffic | Spatial queries, Bigtable para tiles, traffic con Pub/Sub + Dataflow |
| URL Shortener | Hash vs counter, colisiones, cache, analytics, rate limiting | ¿Qué pasa con QPS >100K? Spanner vs Bigtable, base62 encoding |
| Rate Limiter distribuido | Token/leaky bucket, sliding window, Redis atómico, sincronización entre nodos | Race conditions, fail-open vs fail-closed, costo de Redis vs memoria local |
| Twitter timeline | Fan-out on write vs read, celebrities, hybrid approach, Bigtable | Justin Bieber problem (100M followers), eventually consistent timeline |
| WhatsApp / Chat | WebSockets, presencia, mensajes ordenados, push, E2E encryption | Mensajes offline, message ordering, group fan-out, leer recibos |
| Typeahead / Autocomplete | Trie, prefix index, ranking por popularidad, edge serving | Latencia <100ms, top-K en cada nodo, actualización de popularidad |
| Web Crawler | URL frontier, dedup, robots.txt, politeness, distributed BFS | Bloom filter + Bigtable, trampa de URLs infinitas, idioma/relevancia |
| Distributed Cache | Consistent hashing, replicación, eviction (LRU), invalidación | Cache stampede, hot keys, jittered TTL |
| Notification system | Multi-channel (push/email/SMS), idempotencia, retry, prioridad | No spamear, dedup por user+template, fan-out por canal |
| Payment / Order system | ACID, idempotency keys, saga pattern, exactly-once, ledger | Doble cobro, distributed transactions, reconciliación |
| Distributed counter | Sharded counters, eventually consistent, hot key mitigation | Cómo contar likes/views a 1M QPS sin hot partition |
🎤 Frases listas para usar
- "Antes de diseñar, déjame clarificar requisitos y estimar escala."
- "El cuello de botella más probable es X. Lo mitigaría con Y."
- "Hay un trade-off entre consistencia y latencia. Yo elegiría..."
- "Para esto usaría Spanner porque necesito consistencia fuerte global."
- "Esto es read-heavy, así que cache agresivo y replicación."
- "Para evitar hot partitions, voy a salt el key con..."
🚀 Si te queda tiempo, menciona
- Multi-region: failover, latencia regional
- Backups & DR: RPO/RTO, point-in-time recovery
- Cost optimization: tiered storage, spot/preemptible
- Compliance: GDPR, data residency, audit logs
- Internationalization: i18n, multi-currency, multi-timezone
- A/B testing & feature flags
- Chaos engineering & game days