El problema
Este proyecto explora qué sucede cuando una petición atraviesa múltiples servicios y sistemas de mensajería asíncrona. El objetivo es generar tráfico, mover eventos estructurados por rutas de procesamiento distintas y hacer observable el resultado.
Mi contribución
Desarrollé este proyecto de Sistemas Operativos 1 de forma individual, incluyendo servicios de aplicación, integraciones de mensajería, configuración de contenedores, manifiestos de Kubernetes y ruta de monitoreo.
Arquitectura técnica
Locust genera peticiones que llegan a una API en Rust por medio de ingress. El servicio en Rust reenvía datos a una API en Go y a un cliente gRPC. Servidores gRPC separados publican mensajes en Kafka y RabbitMQ.
Consumidores leen los mensajes y escriben información procesada en Redis y Valkey. Grafana provee visualización de los resultados. Los contratos de aplicación usan payloads de clima; el foco de este caso es la arquitectura de procesamiento.
Los manifiestos de Kubernetes describen deployments, servicios, ingress y recursos de brokers. Docker empaqueta los servicios y la documentación del laboratorio incluye Harbor como registro de imágenes.
Por qué estos componentes
- Rust y Go ofrecen dos implementaciones de servicio conectadas por interfaces explícitas.
- gRPC y Protobuf definen el contrato de comunicación entre componentes.
- Kafka y RabbitMQ crean rutas asíncronas distintas para estudiar comportamiento productor-consumidor.
- Kubernetes define cómo se despliegan y conectan los servicios.
- Locust y Grafana permiten generar actividad y observar su salida.
Resultados y limitaciones
El resultado es un laboratorio multiservicio implementado, con código fuente, manifiestos de despliegue y visualización documentada. El repositorio permite inspeccionar la ruta de la petición y los componentes de mensajería.
No se hace una afirmación universal de que un protocolo específico o una réplica adicional hagan el sistema más rápido. Conclusiones sobre throughput, latencia y escalamiento requieren mediciones comparables bajo límites de recursos conocidos. Este caso no publica benchmarks sin validar.
Lecciones de ingeniería
Este proyecto conecta mi interés por Docker y Kubernetes con el comportamiento de la aplicación dentro del clúster. La orquestación se vuelve realmente útil cuando se combina con comprensión de contratos, procesamiento asíncrono y puntos donde una petición puede degradarse o fallar.
