Project 02
Delphos
A distributed architecture that combines application processing, RAG, messaging and specialised workers, connecting Java, Rust and Python components in a service-oriented infrastructure.
- Role
- Systems Architect & Full-Stack Developer
- Context
- Internship · Alfabra Elevadores
- Period
- 2025 – 2026
- Status
- Active development
Problem
Enterprise document ingestion and LLM retrieval pipelines suffer from high latency and tight coupling when processing unstructured data across multiple language runtimes.
Context
Delphos is a modular platform for orchestrating AI agents with retrieval-augmented generation, built during my internship at Alfabra Elevadores. The code is private, so this case study covers the architecture and my role without linking to the source.
Objective
Unify high-throughput document processing in Rust with enterprise business policies in Java and autonomous multi-agent crews in Python.
Architecture
A Next.js frontend talks to a Java and Spring Boot core. The core enqueues jobs on RabbitMQ, and specialised workers for ingestion, RAG and agent crews process them asynchronously. Rust services handle parallel data processing, a Python worker runs the agent crews with CrewAI, and embeddings are stored in PostgreSQL with pgvector. Documents go to MinIO or S3 object storage, generation runs on Vertex AI with Gemini, and the services are packaged with Docker.
Stack
Decisions
Low coupling between modules
Modules follow a clean architecture so that a later move to separate services stays open.
Work leaves the core through a queue
The core enqueues jobs on RabbitMQ; workers process them asynchronously.
More than one model provider
Vertex AI with Gemini is the provider, with a hosted and a local fallback.
Implementation
Designed the reactive RabbitMQ message schema, wrote the Java 21 Spring Boot core REST API with Spring Security and pgvector persistence, and integrated high-performance document parsing workers in Rust.
Results
- Distributed multi-runtime architecture running asynchronously with persistent vector search.
Limitations
- Production cloud scaling requires managed Kubernetes clustering.
Evidence
Each record backs a claim made above; the reference beside a result, a limitation or a decision points here.
Services and the queue between them
Frontend, core, queue, workers and vector storage, drawn from the README.
Low coupling between modules
The repository keeps architectural decision records.
Java, Rust and Python in one repository
The three runtimes are joined in one repository, which is private and not linked here.