Go en producción

La carga real cambia las preguntas

En laboratorio, el throughput suele dominar la conversación. En producción, la previsibilidad y la capacidad de explicar el comportamiento importan tanto como la velocidad.

• Integraciones externas con latencias y errores fuera de nuestro control.
• Un área administrativa con sesión por cookie y permisos explícitos.
• Observabilidad suficiente para diagnosticar causas y no solo síntomas.
• Caché híbrida que reduce costo sin convertir Redis en un punto único de fallo.

Límites antes que escala

El arranque define el espacio operativo: pools, timeouts, concurrencia y health checks se configuran antes de aceptar la primera petición.

• GOMAXPROCS y garbage collection ajustados con perfiles reales de CPU y memoria.
• Pool PostgreSQL con límites explícitos de apertura, inactividad y vida útil.
• Servidor HTTP con body limit, buffers y timeouts finitos.
• Readiness que impide recibir tráfico antes de que las dependencias esenciales estén listas.

“Una cola infinita no es resiliencia. Ante un pico, rechazar pronto y recuperarse rápido es mejor que acumular trabajo hasta colapsar.

El camino crítico debe ser simple

La mayor parte de la mejora vino de eliminar trabajo, controlar asignaciones e impedir que dependencias lentas ocuparan recursos indefinidamente.

• Serialización eficiente, validación en la frontera y buffers reutilizables.
• Clientes HTTP compartidos, pooling de conexiones y timeout por etapa.
• Compresión y ETag solo cuando el costo total justificaba el beneficio.
• Medición por ruta para optimizar a partir de evidencia de producción.

La caché es una estrategia de disponibilidad

Redis reduce el read path, pero no debe controlar por sí solo la disponibilidad. El diseño incluye fallback local limitado y TTLs acordes con la volatilidad de los datos.

• Redis como capa principal, con TTL e invalidación explícitos.
• Caché local limitada para respuestas esenciales durante inestabilidad.
• Claves versionadas y métricas de hit, miss, error y latencia.
• Eviction previsible para impedir crecimiento silencioso de memoria.

“Cuando Redis falla, la plataforma debe perder capacidad, no desaparecer.

Las métricas deben responder preguntas

Los dashboards fueron diseñados a partir de decisiones operativas: ¿debemos escalar, limitar, revertir o investigar una dependencia?

• Histogramas de latencia y resultados por ruta normalizada.
• Tamaño de request y response para detectar payloads anómalos.
• Señales del runtime: CPU, heap, goroutines y pausas de GC.
• SLOs y alertas orientados al impacto, sin ruido imposible de accionar.

“Normalizar parámetros de ruta evitó cardinalidad descontrolada y mantuvo Prometheus utilizable durante incidentes.

Controles cerca de la frontera

El área administrativa usa sesiones protegidas y RBAC explícito. La autorización permanece en el servidor, cerca de la operación que protege.

• Cookies HttpOnly, Secure y SameSite adaptadas al flujo.
• Permisos declarativos y auditoría para operaciones sensibles.
• Límites de payload y validación antes de la lógica de negocio.
• Herramientas de diagnóstico expuestas solo en entornos controlados.

Los errores que cambiaron el diseño

Los patrones más fuertes surgieron de fallos observados. Cada incidente se convirtió en un cambio verificable, no solo en documentación.

• La cardinalidad de métricas llevó a normalizar labels obligatoriamente.
• La dependencia total de Redis llevó a un fallback local limitado.
• Los retries sin presupuesto llevaron a backoff, jitter y límites.
• El logging excesivo llevó a muestreo y niveles según el entorno.

Lo que verificaría antes del próximo deploy

El rendimiento sostenible es una propiedad de todo el sistema y debe estar protegido por automatización.

• Timeouts, pools y body limits cubiertos por pruebas de contrato.
• Caché con fallback, TTL, eviction y telemetría verificables.
• Rutas normalizadas y alertas vinculadas a SLOs claros.
• Readiness, rollback y prueba de carga representativa antes del release.