Java lleva décadas dominando el backend enterprise. Robusto, maduro, con el ecosistema de librerías más amplio del mundo — y con una reputación de ser pesado, lento de arrancar y consumidor voraz de memoria. Quarkus cambió esa ecuación completamente.
El problema que Quarkus resuelve
Un servidor Spring Boot estándar el framework Java más popular tarda entre 8 y 15 segundos en arrancar y consume entre 300MB y 600MB de RAM en reposo. En un entorno cloud donde los pods de Kubernetes necesitan escalar horizontalmente en segundos ante picos de tráfico, esos números son un problema de costo y latencia.
Quarkus, desarrollado por Red Hat (IBM) y lanzado en 2019, fue diseñado desde cero para contenedores y Kubernetes. Los números en producción:
| Métrica | Spring Boot | Quarkus JVM | Quarkus Native |
|---|---|---|---|
| Tiempo de arranque | 8–15 segundos | 0.8–2 segundos | 0.014 segundos |
| Memoria en reposo | 300–600 MB | 150–250 MB | 25–50 MB |
| Throughput (req/seg) | ~28,000 | ~33,000 | ~30,000 |
| Costo cloud (relativo) | 100% (baseline) | ~60% | ~30% |
Por qué el arranque en milisegundos importa en fintech
En una arquitectura de microservicios bancaria, cuando llega un pico de transacciones de fin de mes, Kubernetes necesita escalar los pods horizontalmente — crear nuevas instancias del servicio en segundos. Si cada instancia tarda 12 segundos en arrancar, las primeras transacciones del pico llegan a un servicio que aún está inicializándose.
Con Quarkus Native (compilado con GraalVM), el servicio arranca en 14 milisegundos. El pod está listo antes de que el request llegue. Esto es crítico para sistemas de pagos con SLAs de disponibilidad del 99.9%.
Quarkus en el stack de Ab4cus
Usamos Quarkus para los servicios de compliance y procesamiento transaccional — los módulos con mayor carga y más estrictos requerimientos de latencia. El motor AML AIRPRISE de BAS, nuestro sistema de KYC/KYB, corre sobre Quarkus en modo JVM con el perfil reactivo activado.
La integración con nuestro API Gateway NestJS usa REST con autenticación Bearer — la comunicación entre el mundo TypeScript y el mundo Java es clean, sin fricción, con contratos bien definidos.
¿Cuándo usar Quarkus vs. NestJS en Ab4cus?
- Quarkus (Java): servicios de alta carga, procesamiento transaccional, reglas AML complejas, integración con sistemas core banking legacy, cuando el cliente ya tiene equipo Java
- NestJS (TypeScript): API Gateway, servicios de usuario, integraciones con terceros, cuando se necesita velocidad de desarrollo y el equipo domina TypeScript
No es una competencia es una división de responsabilidades según las fortalezas de cada tecnología.
0 Comentarios