{
 "subtemas": [],
 "tarjetas": [
  {
   "sub": "APIs y edge",
   "q": "Gateway anti-patrones: lo que NUNCA debe hacer",
   "a": "Lógica de negocio en el gateway (descuentos, reglas) → cambio de negocio = deploy del gateway (cuello).\nTransformaciones complejas de payload en cada request (latencia + imposibles de debuggear).\nBase de datos propia del gateway.\nEl gateway: routing, auth token validation, rate limit, TLS, telemetría — NADA más.",
   "nivel": "intermedio",
   "clave": false
  },
  {
   "sub": "APIs y edge",
   "q": "BFF (Backend for Frontend): el patrón que resuelve el disagreement",
   "a": "Un backend POR tipo de cliente (BFF-web, BFF-mobile): cada uno agrega/da forma a los datos como el cliente los necesita.\nResuelve: 'la API genérica no sirve a nadie' y el choca-de-equipo frontend/backend.\nDueño: el EQUIPO DEL CLIENTE (no un equipo central).\nCosto: duplicación controlada — compartida por libs comunes de dominio.",
   "nivel": "intermedio",
   "clave": true
  },
  {
   "sub": "APIs y edge",
   "q": "GraphQL entre microservicios: cuándo y las trampas",
   "a": "Valor: el cliente pide exactamente lo que quiere, un endpoint, menos round-trips.\nFederación (Apollo): cada micro publica su parte del supergraph — composición de schema.\nTrampas: resolver N+1 (dataloader obligatorio), autorización por campo, caché HTTP perdida, consultas destructivas (deep queries → depth/complexity limits).\nÚsalo en el edge (BFF), no como capa interna entre servicios.",
   "nivel": "intermedio",
   "clave": false
  },
  {
   "sub": "APIs y edge",
   "q": "Contratos en el edge: schema-first y validación en runtime",
   "a": "OpenAPI/Proto ES el contrato: genera server stubs, client SDKs, mocks y documentación desde UNA fuente.\nRuntime: validar request/response contra el schema (springdoc + validator, o gateway) — desviaciones fallan rápido.\nCI: spectral lint (naming, errores consistentes), oasdiff para breaking changes entre versiones.\nEl contrato vive, no es un PDF.",
   "nivel": "intermedio",
   "clave": false
  },
  {
   "sub": "APIs y edge",
   "q": "Webhooks salientes: entrega confiable a terceros",
   "a": "Firma: HMAC-SHA256 del body + timestamp en header (el receptor valida — anti-replay con ventana).\nEntrega: cola con reintentos exponenciales (horas, no segundos), circuit breaker por endpoint, DLQ visible.\nVersionado del payload (header X-Event-Type) y docs de verificación.\nReplay tool para el tercero (reenviar eventos de un rango) — reduce soporte 10x.",
   "nivel": "avanzado",
   "clave": false
  },
  {
   "sub": "APIs y edge",
   "q": "API composition vs CQRS read model: tabla de decisión",
   "a": "Composition: pocos servicios (2-4), latencias bajas, filtros simples, datos frescos requeridos.\nRead model (CQRS): muchos servicios, filtros/agregaciones complejas, volumen alto de lecturas, staleness de segundos tolerable.\nHíbrido real: composition para detalle (fresco), read model para listados/búsqueda (rápido).\nNo uses CQRS para todo: costo de mantener proyecciones.",
   "nivel": "intermedio",
   "clave": true
  },
  {
   "sub": "APIs y edge",
   "q": "Idempotency-Key: el estándar para POSTs críticos",
   "a": "Cliente genera UUID por INTENTO LÓGICO (no por retry) y lo manda en header.\nServidor: guarda key → resultado (tabla/Redis con TTL 24h). Reintento con misma key = devuelve el resultado original SIN re-ejecutar.\nStripe lo popularizó; también para consumidores de colas.\nDetalle: si la primera petición está EN CURSO, segunda espera o 409 — no duplicar.",
   "nivel": "intermedio",
   "clave": true
  },
  {
   "sub": "Seguridad",
   "q": "Flujo Authorization Code + PKCE: por qué es EL estándar web/móvil",
   "a": "1) App redirige al IdP con code_challenge (hash del verifier).\n2) Usuario loguea EN EL IDP (credenciales nunca tocan tu app).\n3) Vuelve con code de un solo uso → app intercambia code+verifier por tokens (backend o SPAs públicos).\nPKCE evita que un code interceptado sirva sin el verifier.\nImplicit flow: DEPRECIADO (tokens en URL). Client Credentials: solo service-to-service.",
   "nivel": "intermedio",
   "clave": false
  },
  {
   "sub": "Seguridad",
   "q": "OIDC: qué añade sobre OAuth2 (y los 3 tokens)",
   "a": "OIDC = OAuth2 + capa de IDENTIDAD: id_token (JWT con quién es el usuario: sub, email), userinfo endpoint, discovery (/.well-known/openid-configuration), scopes (openid profile email).\naccess_token: para llamar APIs (autorización). refresh_token: renovar sin re-login.\nEn microservicios: validas access_token (JWT) por servicio; el id_token es para el CLIENTE, no para APIs.",
   "nivel": "intermedio",
   "clave": false
  },
  {
   "sub": "Seguridad",
   "q": "On-behalf-of y token exchange: propagar identidad entre servicios",
   "a": "Problema: servicio A llama a B — ¿token del USUARIO o del servicio?\nToken exchange (RFC 8693): A intercambia el token del usuario por uno delegado para B (audience B, act={sub de A}) — B ve QUIÉN es el usuario y QUIÉN llamó.\nAlternativa simple: propagar el token original + header interno firmado.\nAuditoría correcta requiere la cadena completa.",
   "nivel": "avanzado",
   "clave": false
  },
  {
   "sub": "Seguridad",
   "q": "Autorización centralizada vs por servicio (OPA/sidecar)",
   "a": "Por servicio: cada uno implementa sus reglas (simple, se dispersa).\nCentral policy engine (OPA/Rego como sidecar o librería): políticas unificadas, testables, auditables; servicio pregunta '¿puede X hacer Y sobre Z?'.\nDatos necesarios para decidir (jerarquías, roles finos) → servicio de autorización con caché.\nBalance: reglas de dominio en el micro, políticas transversales centralizadas.",
   "nivel": "avanzado",
   "clave": false
  },
  {
   "sub": "Seguridad",
   "q": "mTLS entre servicios: qué resuelve y su costo",
   "a": "Ambos se autentican con certificados → sin credenciales robadas no hay llamadas (zero trust interno); cifrado integral; identidad para el audit log.\nCosto: emisión/rotación automática (service mesh lo hace: Istio SPIFFE), latencia de handshake (keep-alive mitiga).\nSin mesh: alternativa pragmática = red privada + token de servicio firmado.",
   "nivel": "avanzado",
   "clave": false
  },
  {
   "sub": "Seguridad",
   "q": "Secrets en un ecosistema de microservicios: patrón completo",
   "a": "Fuente única: Secret Manager/Vault (nunca git, nunca imagen).\nEntrega: sidecar/CSI que inyecta como archivo (rotación sin restart) o variable al arranque.\nAcceso: identidad del servicio (SA/workload identity) con rol mínimo por secreto.\nAuditoría: quién leyó qué cuándo. Rotación: automatizada con doble-validación (ver tarjeta de rotación).",
   "nivel": "intermedio",
   "clave": false
  },
  {
   "sub": "Seguridad",
   "q": "Supply chain de microservicios: de commit a despliegue confiable",
   "a": "SLSA niveles: build reproducible y provable (provenance firmada), dependencies escaneadas (Dependabot/Snyk), imágenes distroless escaneadas (Trivy/AR scanning), firma cosign, admisión solo firmadas (Binary Auth/K8s admission).\nSBOM por release (syft) para responder '¿tenemos log4j?' en minutos.\nBase images propias actualizadas semanalmente.",
   "nivel": "avanzado",
   "clave": false
  },
  {
   "sub": "Seguridad",
   "q": "PII entre microservicios: minimización y marcado",
   "a": "Envía el MÍNIMO: el servicio de pedidos no necesita la fecha de nacimiento del cliente (necesita cliente_id y nombre).\nEventos con PII: cifrar campos sensibles (crypto-shredding para GDPR), o tokenizar.\nMarcado de esquemas: anotación/classification en el schema registry (pii=email) → pipelines aplican mask automáticamente.\nInventario de PII por servicio (data mapping) — requisito de auditorías.",
   "nivel": "intermedio",
   "clave": false
  },
  {
   "sub": "Seguridad",
   "q": "Rate limiting por identidad vs por IP: cuándo cada uno",
   "a": "Por IP: anónimos, protección DDoS gruesa (y castiga NAT corporativos).\nPor identidad/API key: clientes autenticados — el límite justo y negocio-relevante (plan free/pro).\nCombinado típico: IP en el edge (Armor/WAF), identidad en el gateway/servicio.\nHeaders informativos (X-RateLimit-*) y 429 con Retry-After — el cliente que respeta es el cliente que no rompe.",
   "nivel": "intermedio",
   "clave": false
  },
  {
   "sub": "Seguridad",
   "q": "Zero trust en una frase aplicado a microservicios",
   "a": "Nunca confíes en la red: cada llamada se autentica y autoriza explícitamente (mTLS + tokens + políticas por servicio), minimiza privilegios, asume brecha.\nContrario al 'castillo y foso' (VPN = dentro confío).\nImplementación progresiva: identidad de servicios → mTLS → políticas por método → auditoría continua.",
   "nivel": "intermedio",
   "clave": false
  }
 ]
}