ADR-010: lenguajes y uso de gRPC
Aceptado el 10/11/2026 por Andrés. Complementado por ADR-025 (segunda llamada gRPC interna, de oms-adapter a order-service; sin implementar al 15/11/2026).
Decisión
- Servicios de dominio en Java con Spring Boot.
- Mocks y adaptadores en Node.js con Express.
- gRPC en un solo punto:
order-servicehaciainventory-servicepara reservar, confirmar y liberar. REST hacia afuera; eventos en lo demás. - No se agrega un servicio en Go ni en Rust.
Por qué
- Spring Boot: probablemente el stack del evaluador; autoinstrumentación de OpenTelemetry madura.
- Dos lenguajes sobre la misma plataforma prueban que el contrato de plataforma no depende del lenguaje. Cuatro no prueban más y cuestan el doble.
- gRPC donde importan latencia y contrato estricto, y solo ahí.
- Go o Rust: el requisito de latencia se cumple con arquitectura (modelo de lectura), y la ruta caliente ya pasa por KrakenD (Go) y Envoy (C++). Razonamiento completo en
docs/plataforma/04-stack.md.
Qué se sacrifica
- Memoria y arranque de la JVM en un clúster pequeño.
- Dos cadenas de herramientas.
Cuándo se revisaría
Si la función de aptitud F1 falla y el perfil señala al servicio, no a la red ni a Redis.