{
 "subtemas": [],
 "tarjetas": [
  {
   "sub": "Plataforma y despliegue",
   "q": "Plantilla de microservicio (service template): qué incluye",
   "a": "Estructura lista con: health endpoints, métricas/tracing, logging JSON, config externalizada, resiliencia por defecto (timeouts), Dockerfile distroless, CI/CD pipeline, tests de ejemplo, README/runbook, chart de Helm/Terraform module.\nGenerada con cookiecutter/backstage template.\nBeneficio: un servicio nuevo nace OBSERVABLE y seguro en día 1; equipos no reinventan el cableado.",
   "nivel": "intermedio",
   "clave": false
  },
  {
   "sub": "Plataforma y despliegue",
   "q": "Requests y limits en K8s: cómo definirlos bien",
   "a": "Requests: lo que el POD asegura (planifica el scheduler, base del HPA) — usa p50-p75 real.\nLimits: techo (CPU se throttles, memoria OOMKilled) — p99 con margen ~20-30%.\nMedir con VPA en modo recomendación antes de fijar.\nRequests altos = dinero desperdiciado (nodos sobredimensionados); bajos = throttling y OOM.",
   "nivel": "intermedio",
   "clave": true
  },
  {
   "sub": "Plataforma y despliegue",
   "q": "PodDisruptionBudget y surges: deploys que no degradan",
   "a": "PDB: mínimo de réplicas disponibles durante drenajes (nodos updates, autoscaler) — minAvailable: 2 o maxUnavailable: 1.\nRolling: maxSurge (cuántos pods extra al desplegar) + maxUnavailable (cuántos pueden faltar) — típico 25/25.\nSin PDB, un upgrade de nodos puede tumbar tu servicio completo.\nreadiness gate correcta = prerequisite de todo esto.",
   "nivel": "intermedio",
   "clave": false
  },
  {
   "sub": "Plataforma y despliegue",
   "q": "HPA con métricas custom: escalar por negocio, no solo CPU",
   "a": "CPU engaña en I/O-bound (hilos bloqueados ≠ CPU alta).\nHPA v2 con métricas externas: longitud de cola (Pub/Sub backlog), p99 latencia, QPS por pod (via Prometheus Adapter/KEDA).\nKEDA: ScaledObject por consumidor — escala a 0 con colas vacías, replica por lag.\nObjetivo tipo: '1 pod por 100 mensajes pendientes'.",
   "nivel": "avanzado",
   "clave": false
  },
  {
   "sub": "Plataforma y despliegue",
   "q": "Feature flags: liberar ≠ desplegar",
   "a": "Deploy = código en prod; release = usuarios lo ven. Flags separan los dos.\nTipos: release (apagar feature nueva), ops (kill switch), experiment (A/B %), permission (beta users).\nGobernanza: dueño, expiración, limpieza periódica — flags muertos son deuda técnica invisible.\nTesting: CI corre con flags en AMBOS estados (el flag es una rama lógica).",
   "nivel": "intermedio",
   "clave": true
  },
  {
   "sub": "Plataforma y despliegue",
   "q": "Migraciones de schema compatibles: el contrato entre deploys",
   "a": "Durante un deploy conviven versión N y N+1 → el schema debe servir a AMBAS.\nOrden: ADD nullable → backfill por batches → deploy código que usa la nueva → (release siguiente) DROP/RENAME viejo.\nProhibido: renombrar columnas directas (use rename + vista o doble escritura temporal).\nHerramientas: Flyway/Liquibase + CI que valida contra versión previa del código.",
   "nivel": "avanzado",
   "clave": false
  },
  {
   "sub": "Plataforma y despliegue",
   "q": "Canary automated: qué métricas deciden promover",
   "a": "Comparar canary vs baseline (stable) en: error rate, p99 latencia, throughput esperado, y señales de negocio (conversion, checkout success).\nReglas de decisión: si canary empeora > X% con significancia estadística → rollback automático.\nHerramientas: Argo Rollouts (analysis template), Flagger (promote/rollback automático), Istio traffic split.\nSin métricas automáticas, 'canary' es solo un deploy lento a mano.",
   "nivel": "avanzado",
   "clave": false
  },
  {
   "sub": "Plataforma y despliegue",
   "q": "Ambientes efímeros (preview environments)",
   "a": "Por PR: despliega el servicio + dependencias simuladas en namespace/URL efímero (pr-1234.tuapp.com).\nValidación real del reviewer: click, no imaginar.\nCiclo: crear al abrir PR, destruir al cerrar (costo 0 en reposo).\nCon datos: subsets anonimizados o sintéticos — nunca PII de prod en previews.",
   "nivel": "intermedio",
   "clave": false
  },
  {
   "sub": "Plataforma y despliegue",
   "q": "Sidecar, ambassador, adapter: patrones de contenedor auxiliar",
   "a": "Sidecar: acompaña al principal compartiendo su vida (proxy, collector de logs, sync de secrets).\nAmbassador: proxy a dependencias (cloud-sql-proxy, connector) — la app habla 'localhost'.\nAdapter: expone la app en formato estándar (exporter de métricas legacy).\nK8s: contenedores del mismo pod, localhost compartido, lifecycle juntos.",
   "nivel": "intermedio",
   "clave": false
  },
  {
   "sub": "Plataforma y despliegue",
   "q": "Stateless de verdad: los 5 estados escondidos que rompen el scaling",
   "a": "1) Sesiones en memoria (sticky sessions). 2) Cachés locales por instancia (respuestas inconsistentes tras scale). 3) Archivos en disco local. 4) Contadores/timers en memoria. 5) Scheduled jobs corriendo en todas las réplicas.\nFixes: JWT/Redis sessions, caché distribuida, GCS/S3 para archivos, DB sequences, ShedLock/scheduler externo.\nTest: matar una réplica en caliente — ¿se pierde algo?",
   "nivel": "intermedio",
   "clave": true
  },
  {
   "sub": "Plataforma y despliegue",
   "q": "Progressive delivery: el continuo de estrategias",
   "a": "Recreate (downtime) → rolling (default k8s) → blue/green (switch instantáneo, doble costo temporal) → canary (% creciente con métricas) → shadow/mirror (tráfico real copiado sin respuesta — probar con riesgo 0).\nElegir por riesgo del cambio y madurez de métricas.\nShadow para cambios de alto riesgo (nuevo motor de pricing) — valida con tráfico real sin exponer usuarios.",
   "nivel": "intermedio",
   "clave": false
  },
  {
   "sub": "Plataforma y despliegue",
   "q": "¿Qué es un service mesh y cuándo NO vale la pena?",
   "a": "Capa de infra (Istio/Linkerd) que inyecta proxies para mTLS, retries, timeouts, traffic split, telemetría — SIN tocar el código.\nVale: 10+ servicios, multi-equipo, zero-trust exigido, canary sofisticado.\nNo vale: pocos servicios, equipo chico (operar Istio es un trabajo), latencia sensible al extremo.\nAlternativa media: librerías in-app (Resilience4j) + gateway.",
   "nivel": "avanzado",
   "clave": false
  },
  {
   "sub": "Testing y calidad",
   "q": "Contract testing consumer-driven (Pact): el flujo",
   "a": "1) Consumer escribe expectativas → genera pact file (JSON de interacciones).\n2) Pact se publica al broker.\n3) Provider verifica el pact contra su implementación real.\n4) can-i-deploy: CI del provider verifica que TODOS los consumidores activos funcionan antes de desplegar.\nElimina el ambiente de integración compartido como cuello de botella.",
   "nivel": "avanzado",
   "clave": true
  },
  {
   "sub": "Testing y calidad",
   "q": "Testcontainers: BDs reales en tests de integración",
   "a": "Docker + testcontainers levanta Postgres/Kafka/Redis reales por sesión de test (o singleton compartido).\nPruebas lo que verás en prod: migraciones Flyway reales, dialecto real, transacciones reales.\nPatrón singleton container para velocidad (una BD por suite, limpieza por test).\nAlternativa en CI: contenedores sidecar del pipeline.",
   "nivel": "intermedio",
   "clave": false
  },
  {
   "sub": "Testing y calidad",
   "q": "Testing en producción: formas seguras",
   "a": "Feature flags para experimentos controlados, canary como test de tráfico real, synthetic probes (transacciones sintéticas constantes), chaos experiments acotados, shadow traffic (duplicar tráfico sin responder).\nPre-requisitos: aislamiento de datos de test, IDs marcados (test-user), alertas que reconozcan tests.\nNunca 'probemos en prod' sin blast radius definido.",
   "nivel": "avanzado",
   "clave": false
  },
  {
   "sub": "Testing y calidad",
   "q": "E2E en microservicios: la pirámide invertida a evitar",
   "a": "Anti-patrón: suite E2E gigante que cruza 10 servicios — frágil (cualquier deploy rompe tests ajenos), lenta, flaky, difícil de atribuir.\nReemplazo: contract tests entre pares + component tests por servicio (stubs de dependencias) + pocos E2E críticos (login, compra).\nCada equipo ejecuta sus tests contra pacts, no contra deploys de otros.",
   "nivel": "intermedio",
   "clave": false
  },
  {
   "sub": "Operación y organización",
   "q": "Runbook: el documento que salva el on-call",
   "a": "Por servicio: qué hace (1 párrafo), arquitectura (diagrama), dependencias y sus dashboards, alertas explicadas (qué significa + qué hacer), procedimientos comunes (restart seguro, drain, backfill), escalado a quién (escala de contacto), límites y cuotas.\nEnlazado desde CADA alerta.\nTest real: alguien ajeno al equipo lo sigue en un game day.",
   "nivel": "intermedio",
   "clave": false
  },
  {
   "sub": "Operación y organización",
   "q": "On-call sostenible: rotación, severidades y handoff",
   "a": "Rotación primario/backup semanal (mínimo 6 personas para no quemar), compensación o reducción de tareas, severidades definidas (SEV1 despierta, SEV3 ticket).\nHandoff documentado: qué pasó, qué está pendiente, qué alertas están silenciadas y por qué.\nMétrica de salud: páginas por semana por persona (<2 sostenible).\nOn-call que nadie quiere = señal de deuda de confiabilidad.",
   "nivel": "intermedio",
   "clave": false
  },
  {
   "sub": "Operación y organización",
   "q": "Incident management: roles en un SEV1",
   "a": "Incident Commander (coordina, no arregla), Comms (stakeholders/status page), Operations (mitiga), Scribe (timeline).\nCanal dedicado + puente de voz; timeline con timestamps desde el minuto 0.\nMitigación primero (rollback/flag/drain), causa raíz DESPUÉS.\nPostmortem en 48h, blameless, action items con fecha.",
   "nivel": "intermedio",
   "clave": false
  },
  {
   "sub": "Operación y organización",
   "q": "FinOps por microservicio: atribuir costo y crear incentivos",
   "a": "Labels/tags por servicio + billing export → costo por servicio/equipo visible mensualmente.\nMétrica de eficiencia: costo por transacción/por usuario (tendencia, no absoluto).\nPresupuesto por equipo con alertas; costos del shared (nats, logging) repartidos por uso.\nEfecto: el equipo que paga por over-provisioning, lo arregla — sin mesa de discusión.",
   "nivel": "intermedio",
   "clave": false
  },
  {
   "sub": "Operación y organización",
   "q": "Deprecar y matar un microservicio: el proceso que nadie documenta",
   "a": "1) Anunciar consumidores (el catálogo lista quién te llama) con fecha límite.\n2) Métrica de tráfico residual → contactar rezagados.\n3) 410 Gone con aviso en la respuesta, luego apagar.\n4) Archivar datos según retención legal, borrar el resto.\n5) Documentar en el catálogo: 'absorbido por X'.\nServicios zombis pagando infra y parches = deuda silenciosa.",
   "nivel": "intermedio",
   "clave": false
  },
  {
   "sub": "Operación y organización",
   "q": "Catalog de servicios (Backstage): para qué sirve de verdad",
   "a": "Inventario: quién es dueño de qué, repos, dashboards, runbooks, SLOs, dependencias (mapa vivo), on-call actual.\nScorecards: madurez de seguridad/observabilidad por servicio — empuja estándares sin perseguir equipos.\nOnboarding: 'nuevo servicio' genera template completo.\nSin catálogo, preguntar '¿quién es dueño de X?' toma días.",
   "nivel": "intermedio",
   "clave": false
  },
  {
   "sub": "Operación y organización",
   "q": "Capacity planning: de la predicción al presupuesto",
   "a": "Datos: crecimiento histórico de QPS/datos, eventos estacionales (Black Friday), margen de seguridad 2x.\nCostos por réplica → presupuesto requerido por trimestre.\nLoad tests que VALIDEN la predicción (¿cada pod realmente aguanta 100 rps?).\nPlan de contingencia: qué se degrada primero si duplica el tráfico (prioridades ya definidas).",
   "nivel": "intermedio",
   "clave": false
  }
 ]
}