Auth y operar tu API

Al finalizar, podrás diseñar e implementar un flujo de recuperación de contraseña que resista los tres ataques documentados en el OWASP Forgot Password Cheat Sheet: enumeración de cuentas (respuesta idéntica exista o no el email), reutilización de tokens (one-time use con marca de consumido en DB) y exposición prolongada (TTL de 15-60 minutos máximo, hash SHA-256 del token en la base de datos, invalidación de sesiones tras el cambio), defendiendo cada decisión con la sección concreta de OWASP ASVS V2 que mitiga.

Al finalizar, podrás implementar OAuth 2.0 Authorization Code flow con PKCE para login social (Google/GitHub) usando NextAuth/Better Auth, justificando cada paso con la RFC 6749 y mitigando los vectores de ataque más comunes (CSRF, redirect URI hijacking, code interception).

Al finalizar, podrás emitir logs JSON estructurados con pino, asignar el nivel correcto a cada evento (trace/debug/info/warn/error/fatal), propagar un request_id de correlación con child loggers y redactar campos sensibles, de modo que tu pipeline de observabilidad pueda filtrar, agrupar y auditar producción sin nuevos despliegues.

Al finalizar, podrás configurar @sentry/node en una API Express, capturar excepciones con Sentry.captureException enriquecidas con user context y request context, añadir breadcrumbs manuales para reconstruir la cronología previa al error, subir sourcemaps al release para que los stack traces de producción apunten a tu código fuente (no al bundle minificado), y diseñar alertas con umbral (≥N eventos nuevos en M minutos) que eviten la fatiga de notificaciones — defendiendo cada decisión con el marco Error Tracking (Sentry 2012, Cramer/Vinegar) + Three Pillars of Observability (Charity Majors, Honeycomb 2016).

Al finalizar, podrás diseñar dos endpoints HTTP separados — GET /health (liveness, respuesta < 100 ms, sin tocar dependencias) y GET /ready (readiness, verifica Postgres + Redis + colas con timeout corto) — devolviendo 200 cuando el servicio puede recibir tráfico y 503 cuando no, configurar los probes correspondientes en Railway/Fly/Kubernetes con initialDelaySeconds y periodSeconds ajustados al arranque real de tu API, y proteger los checks de dependencias externas con un patrón Circuit Breaker (Nygard, 2007) para evitar el anti-patrón del healthcheck-zombie que reinicia tu pod cuando solo está bajo carga.

Al finalizar, podrás instrumentar una API Express con las cuatro métricas mínimas del día 1 — rate de peticiones, tasa de errores, latencia p95 y usuarios activos — exportadas a Prometheus en formato OpenMetrics y visualizadas en Grafana, defendiendo cada elección con el marco RED Method (Wilkie/Weaveworks 2015) + USE Method (Gregg 2012) + Four Golden Signals (Google SRE Book, Beyer et al. 2016), y entendiendo por qué la media de latencia miente y solo los percentiles p50/p95/p99 cuentan la verdad de la experiencia de usuario.

Al finalizar, podrás desplegar una API Node/Python a producción real (Railway, Fly.io o Render) en menos de 10 minutos a partir de un repositorio Git, decidiendo con criterio entre Dockerfile y Nixpacks, configurando DATABASE_URL como variable de entorno, exponiendo un healthcheck dependiente de la DB, separando las migraciones del comando de arranque, y comparando coste mensual proyectado a 100/1000/10000 usuarios para evitar facturas sorpresa — eligiendo plataforma según latencia geográfica (Fly edge en Madrid/Amsterdam) o flujo Git-push (Railway desde GitHub) en función del perfil real del producto.

Al finalizar, podrás aplicar el patrón Expand-Contract (Sadalage 2003, "Refactoring Databases" 2006) para ejecutar cambios de esquema en una base de datos en producción sin downtime, decidir cuándo basta con el patrón aplicado por código y cuándo necesitas una herramienta de migración online (gh-ost o pt-online-schema-change), evitar los anti-patrones bloqueantes (NOT NULL sin default, índices no concurrentes, DROP COLUMN antes de stop-reading) y diseñar un rollback de datos —no solo de código— antes de tocar producción.

Al finalizar, podrás diseñar y operar una estrategia de backup completa para una base de datos PostgreSQL en producción que combine pg_dump diario lógico + PITR continuo (WAL archiving), aplicando la regla 3-2-1 de US-CERT/CISA (3 copias, 2 medios distintos, 1 off-site), definiendo RPO y RTO como decisiones de negocio defendibles (cuántos minutos de datos podés perder y cuántos minutos podés estar abajo), ejecutando un test de restore mensual cronometrado en staging que valida integridad de tablas críticas, y manteniendo el script de recuperación versionado en el repo junto al runbook de incidentes — de modo que ante un fallo real de disco, error humano (DROP TABLE), corrupción lógica o ransomware, podás reconstruir el servicio en el tiempo prometido al cliente con la pérdida de datos máxima definida.

Al finalizar, podrás distinguir cuándo tu API ha cruzado el umbral de "tráfico real" y necesita madurar sus operaciones; definir un SLO conservador (p.ej. 99.5% disponibilidad), calcular su error budget mensual en minutos, configurar una alerta sobre burn rate (no sobre síntomas instantáneos), redactar un runbook ejecutable a las 4 AM para los 3 fallos más probables de tu stack, y conducir una revisión post-incidente "blameless" siguiendo la plantilla Howie de Etsy o el formato Google SRE — defendiendo cada decisión con el marco Site Reliability Engineering (Beyer et al., O'Reilly 2016) + Blameless Postmortems (Allspaw, CACM 2012).