El debate sobre Alpine y musl libc es acertado; para evitar problemas con native modules, a veces prefiero usar imágenes oficiales slim con glibc, ya que son más predecibles en entornos de producción. En cuanto a debugging, un multi-stage build que incluya un stage de desarrollo con herramientas como node-inspector puede separar las preocupaciones sin hinchar la imagen final, pero requiere disciplina en el CI/CD para no desplegar accidentalmente esa capa.
Sobre mantener dos stacks, es un punto crítico que a menudo se subestima. He visto proyectos donde la migración a Go para nuevos servicios creó silos de conocimiento y aumentó la deuda operacional. Si Node escala horizontalmente, optimizar con Fastify y ajustar el garbage collector puede ser más rentable. Para CPU-bound tasks, los workers de Node pueden mitigar limitaciones, aunque Go sigue siendo superior en eficiencia por núcleo.
Para el POC, añadiría métricas de tiempo de startup en frío, ya que en entornos serverless o con autoescalado rápido, esto impacta más que el pico de req/s. ¿Has considerado benchmarks con cargas realistas que simulen tu tráfico, en lugar de pruebas sintéticas?
