{
 "subtemas": [],
 "tarjetas": [
  {
   "sub": "Mensajería y eventos",
   "q": "Pub/Sub vs Kafka vs RabbitMQ: mapa conceptual",
   "a": "Pub/Sub: managed global, push/pull, at-least-once, sin claves de partición complejas — el default GCP.\nKafka: log distribuido con particiones y consumer groups, replay nativo, exactly-once con transacciones — streaming pesado y ecosistema (self-managed o Dataproc/Confluent).\nRabbitMQ: colas inteligentes con routing (exchanges) — patrones de cola enterprise clásicos.",
   "nivel": "intermedio",
   "clave": false
  },
  {
   "sub": "Mensajería y eventos",
   "q": "Push vs Pull en Pub/Sub: cuándo cada uno",
   "a": "Pull: el consumidor pide mensajes (control total de ritmo, ideal para workers y batch).\nPush: Pub/Sub llama a tu endpoint HTTPS (webhooks, Cloud Run) — simple, escala automática, pero control limitado y el receptor debe responder 2xx rápido.\nPush con OIDC token para autenticar el caller.\nStreaming pull: alta tasa con cliente gestionando más eficientemente.",
   "nivel": "intermedio",
   "clave": true
  },
  {
   "sub": "Mensajería y eventos",
   "q": "Ack deadline, max delivery y dead letter: el ciclo de vida del mensaje",
   "a": "Mensaje entregado queda 'in flight' hasta ack o expiración del ackDeadline (10-600s) → modAck para extender en procesamiento largo.\nTras N intentos (delivery attempt/dead letter policy en la subscription) → topic dead-letter con header de causa.\nConsumidor idempotente OBLIGATORIO (at-least-once).\nSeek permite re-entregar (snapshot/fecha) para re-procesar.",
   "nivel": "avanzado",
   "clave": false
  },
  {
   "sub": "Mensajería y eventos",
   "q": "Ordering keys: orden garantizado y su costo",
   "a": "messageOrdering=true en publisher + orderingKey (ej. orderId) → mensajes de la MISMA clave llegan en orden al mismo suscriptor.\nCosto: throughput reducido (una clave = una secuencia); si un mensaje falla, se BLOQUEA la clave hasta ack/expiración (entrega la detiene).\nExactly-once delivery (región con feature) refuerza orden + no duplicados.\nAlternativa: procesar orden en el consumidor por versiones/sequence.",
   "nivel": "avanzado",
   "clave": false
  },
  {
   "sub": "Mensajería y eventos",
   "q": "Pub/Sub schemas y filtrado de subscriptions",
   "a": "Schema registry (Avro/Protobuf): valida el payload al publicar — contrato versionado con compatibilidad (backward/forward).\nFilter de subscription: atributos (type: \"order.created\" && region: \"eu\") → cada servicio solo recibe lo suyo sin fan-out manual.\nBigQuery subscription: escribe directo a tabla (ETL sin consumer).\nRetention de mensajes (hasta 31 días) para replay.",
   "nivel": "intermedio",
   "clave": false
  },
  {
   "sub": "Mensajería y eventos",
   "q": "Cloud Tasks vs Pub/Sub: la pregunta que confunde a todos",
   "a": "Pub/Sub: eventos FAN-OUT a muchos suscriptores, throughput masivo, sin control fino de timing.\nCloud Tasks: comandos punto a punto UNO A UNO con control fino: tasa de dispatch (rate limits), schedule en el futuro, retry backoff explícito, token OIDC.\nCasos Tasks: emails con rate limit de proveedor, callbacks programados, throttling a API externa.",
   "nivel": "intermedio",
   "clave": true
  },
  {
   "sub": "Mensajería y eventos",
   "q": "Event-driven en GCP: la arquitectura canónica",
   "a": "Origen: app cambia estado → publica a Pub/Sub (o Eventarc escucha Audit Logs de GCS/BQ).\nEventos fluyen: subscriptions filtradas por tipo → Cloud Run consumers (escalado por mensaje).\nEfectos: BD actualizada, notificaciones, analítica (BigQuery subscription).\nReglas: eventos inmutables en pasado ('PedidoCreado'), payload con id + datos mínimos o claim-check.",
   "nivel": "intermedio",
   "clave": false
  },
  {
   "sub": "Mensajería y eventos",
   "q": "Cloud Scheduler + Workflows: orquestación sin servidores",
   "a": "Scheduler: cron gestionado que llama HTTP/PubSub/AppEngine (UI de cron, timezone).\nWorkflows: orquestador YAML/JSON con pasos, condiciones, retries, llamadas a APIs — el 'paso a paso' serverless (sustituye scripts glue).\nEjemplo: Scheduler diario → Workflow: extraer datos, llamar Cloud Run, si falla retry, notificar.\nBarato y sin infraestructura.",
   "nivel": "intermedio",
   "clave": false
  },
  {
   "sub": "Mensajería y eventos",
   "q": "Idempotencia de consumidores: implementación concreta",
   "a": "Clave = eventId/messageId del evento.\nTabla dedup: INSERT INTO processed(event_id) — si constraint violation, ya procesado → ack y skip (en la MISMA tx del negocio = atómico).\nTTL/purga de la tabla. Redis SETNX con expiración como caché de dedup rápida.\nOperaciones naturales idempotentes: upsert, set estado por versión.",
   "nivel": "intermedio",
   "clave": false
  },
  {
   "sub": "Mensajería y eventos",
   "q": "Poison messages y DLQ handling operativo",
   "a": "Mensaje que SIEMPRE falla (payload inválido): dead-letter policy tras N intentos evita bloquear la cola.\nOperación: monitorear profundidad del DLQ (alerta), inspeccionar causa (header stack/reason), fix del bug, re-publicar corregidos (seek o republish tool).\nSin DLQ: un solo mensaje malo puede parar todo el pipeline.",
   "nivel": "intermedio",
   "clave": false
  },
  {
   "sub": "Analítica de datos",
   "q": "BigQuery: modelo de costos on-demand vs slots",
   "a": "On-demand: pagas por bytes ESCANEADOS (~$6/TB) — el WHERE por columna (columnar) importa; particionar reduce el scan.\nEditions/slots: capacidad reservada (slots por segundo/hora/mensual) — predecible y mejor a escala (sin límites de bytes).\nControles: custom quotas por usuario/proyecto, maximum bytes billed por query, dry run antes de correr.",
   "nivel": "intermedio",
   "clave": false
  },
  {
   "sub": "Analítica de datos",
   "q": "Partitioning y clustering en BigQuery: el 80% de la performance",
   "a": "Partition por DATE/TIMESTAMP (o integer range): cada query con WHERE fecha = 'X' escanea UNA partición (no toda la tabla).\nClustering por columnas frecuentes de filtro (user_id, pais): ordena bloques dentro de la partición → skips.\nResult: terabytes evitados = dinero y velocidad.\nRe-particionar tabla grande: create table partition by... as select.",
   "nivel": "intermedio",
   "clave": true
  },
  {
   "sub": "Analítica de datos",
   "q": "Cargar datos a BigQuery: las 5 rutas",
   "a": "1) Batch load (CSV/Parquet/AVRO desde GCS) — gratis, ideal para cargas grandes puntuales.\n2) Streaming insert (write API) — latencia segundos, costo por GB.\n3) Storage Write API (nuevo, exactly-once, transactions) — el estándar para pipelines.\n4) BigQuery subscription desde Pub/Sub — directo desde mensajería.\n5) Federated queries (tabla externa sobre GCS/Cloud SQL) — sin mover datos.",
   "nivel": "intermedio",
   "clave": false
  },
  {
   "sub": "Analítica de datos",
   "q": "Dataflow (Apache Beam): batch y streaming unificados",
   "a": "Pipeline en Java/Python → corre en managed Dataflow: auto-scaling de workers, exactly-once en streaming.\nCasos: ETL por lotes, procesamiento de streams (ventanas, agregaciones), correcciones tardías (watermarks).\nCosto por vCPU/RAM de workers — tuning con autoscaling y streaming engine.\nAlternativa light: Dataproc (Spark) si el equipo ya tiene Spark.",
   "nivel": "avanzado",
   "clave": false
  },
  {
   "sub": "Analítica de datos",
   "q": "Lakehouse en GCP: GCS + BigQuery + Dataplex",
   "a": "Data lake: GCS (Parquet) como almacenamiento barato por zonas (raw/curated/consumed).\nBigQuery consulta lakehouse: tablas externas / BigLake (metadatos, seguridad a nivel fila/columna, caché).\nDataplex: catálogo, calidad y gobernanza por zonas.\nETL con Dataflow/Dataproc; BI con Looker/Looker Studio.",
   "nivel": "avanzado",
   "clave": false
  },
  {
   "sub": "Analítica de datos",
   "q": "Composer (Airflow gestionado): DAGs como código",
   "a": "Composer = Apache Airflow gestionado: DAGs en Python versionados en GCS, schedule/orquestación con dependencias entre tareas.\nCasos: pipelines ETL multi-step (extraer Cloud SQL → Dataflow → BigQuery → Looker), ML retraining.\nOperación: entorno en su propio GKE (costo fijo mensual notable), monitoring de tasks fallidas.\nAlternativa serverless: Workflows para orquestaciones simples.",
   "nivel": "avanzado",
   "clave": false
  },
  {
   "sub": "Analítica de datos",
   "q": "Looker Studio / Looker: el extremo BI",
   "a": "Looker Studio (gratis): dashboards conectados a BigQuery/Sheets — reportes operativos rápidos.\nLooker (enterprise): capa semántica (LookML) — métricas definidas UNA vez, gobernadas, self-service real.\nPatrón de entrega de datos: BigQuery mart → dashboard ejecutivo.\nEmbed: dashboards embebidos para clientes SaaS.",
   "nivel": "intermedio",
   "clave": false
  },
  {
   "sub": "Analítica de datos",
   "q": "Streaming pipeline canónico: Pub/Sub → Dataflow → BigQuery",
   "a": "Eventos (clicks, sensores, transacciones) → Pub/Sub topic → Dataflow streaming: parse/validate/enriquecer, ventanas por minuto → BigQuery tablas particionadas.\nExactly-once con Storage Write API sink; late data con watermarks.\nMonitoreo: system lag de Pub/Sub, watermarks de Dataflow, frescura de BQ.\nMisma topología sirve para agregados en tiempo real (Firestore/Memorystore sink).",
   "nivel": "avanzado",
   "clave": false
  }
 ]
}