JAVA ~/lucas-eckert/README.md › building VellumHub
Jaraguá do Sul, BR
$ event-driven microservices · JVM · distributed systems

/* backend developer, distributed systems, JVM native */

Lucas
Eckert

// Jaraguá do Sul, BR · Java · Kafka · pgvector · WEG S.A.
const bio =

Backend at WEG S.A., building event-driven microservices on the JVM. Currently working through DDIA — the chapter on replication lag and read-your-writes consistency is reshaping how I think about the read models in VellumHub. // implementing backprop from scratch on weekends

// now
working WEG S.A. — Industrial Learning Program
building VellumHub — embedding pipeline + reactive gateway
reading Designing Data-Intensive Applications · Kleppmann
exploring backpropagation — implementing from scratch, no autograd
## PROJECTS
01
VellumHub FEATURED
Book recommendation platform on the JVM how do you serve recommendations without synchronous coupling?
Java 21 · Kafka · pgvector

Microservices platform built around one constraint: the recommendation service must answer every query with zero synchronous calls to other services. Reactive API gateway, event-driven read models via Kafka ECST, and pgvector similarity search with LangChain4j 384-dim embeddings.

LATENCY CUT
—
v1 → v3
recommendation path
VECTOR DIMS
—
genre vec → dense
LangChain4j semantic
SERVICES
—
zero cross-service
calls at query time
// latency evolution (recommendation path)
v1
~400ms  external Python ML
v2
~100ms  in-JVM pgvector
v3
current  + 384-dim embeddings
// system architecture
client api-gateway WebFlux + Redis JWT · rate-limit user-service catalog-service engagement kafka ECST 4 topics recommendation pgvector HNSW 384-dim embeddings L2-normalized cosine route events query path — zero cross-service calls at read time
  • Event-driven read model — Recommendation Service consumes created-book, updated-book, deleted-book, created-rating via Kafka ECST; every query answered with zero synchronous calls to other services
  • Embedding pipeline — replaced 13-dim genre vectors with LangChain4j AllMiniLmL6V2 384-dim embeddings + L2 normalization; ANN retrieval via HNSW index, re-ranked with 70/30 semantic/popularity blend
  • Reactive gateway — WebFlux entry point centralizing JWT validation and Redis-backed rate limiting per route; built custom over Spring Cloud Gateway for direct pipeline control
  • Architecture evolution — v1 (external Python ML, ~400ms) → v2 (in-JVM pgvector + ECST, ~100ms) → v3 (384-dim semantic embeddings, L2 normalization, API gateway layer)
github ↗ Java 21 · Spring Boot 3.4/4.0 · WebFlux · Kafka · pgvector · LangChain4j · Redis · Docker Compose
02
OpenIT
IoT access control & payment — ESP32, MQTT, reactive backend what does it mean to build a system from hardware to interface, from scratch?
WebFlux · MQTT · ESP32

Automated parking management system — ESP32 detects vehicle entry, Node-RED bridges MQTT to the backend, Spring WebFlux handles the reactive pipeline, Mercado Pago Checkout Pro processes payment, and the gate opens only after the webhook confirms. Six phases, zero human intervention.

FLOW PHASES
6
entry → parking →
payment → confirm → SSE → gate
DDD CONTEXTS
2
access · payment
4-layer clean arch each
REAL-TIME
SSE
WebFlux stream
payment status · no polling
// full system flow — entry to gate release
ENTRY ORCHESTRATION BACKEND PAYMENT FRONTEND ESP32 sensor detects unique code MQTT broker public Node-RED IoT orchestrator MQTT → HTTP pub Spring Boot · WebFlux access context entry log · gate command · exit presentation · app · domain · infra payment context preference · webhook · SSE stream presentation · app · domain · infra HTTP Mercado Pago Checkout Pro PIX · card · boleto preference webhook React / TS payment terminal SSE: poll payment status in real-time request gate open SSE stream gate release — validated payment → Node-RED → MQTT → ESP32 MySQL
  • Node-RED as IoT orchestrator — bridges the MQTT broker to the Spring backend; on entry, subscribes to device events and calls POST /access/entry to persist the record; on gate release, receives POST /open-gate from the backend and publishes the open command back to the ESP32 via MQTT
  • Two DDD bounded contexts with Clean Architecture — access (entry/exit lifecycle, gate coordination) and payment (Mercado Pago Checkout Pro preference creation, webhook confirmation, SSE stream); each context structured across presentation → application → domain → infrastructure layers
  • WebFlux SSE for payment polling — instead of the frontend polling REST every N seconds, the backend holds a reactive SSE connection per payment ID and pushes paid: true the moment the Mercado Pago webhook lands — chosen over WebSocket because the stream is unidirectional and stateless from the server side
  • End-to-end in a team of 3 — full software responsibility: ESP32 firmware, MQTT topology, Node-RED flows, reactive backend, payment integration, and React/TypeScript terminal
github ↗ Java 21 · Spring Boot 3.5 · WebFlux · Node-RED · MQTT · SSE · Mercado Pago SDK · React 19 · TypeScript · MySQL · ESP32 · Docker Compose
03
Vinculo
Graph-native social network — Neo4j as primary data model what changes when you stop pretending a social graph is relational data?
Java 21 · Neo4j

Social network where the graph is the domain model, not a performance optimization. The design question: what does the data layer look like when relationships are first-class citizens?

CONNECTION TYPES
9
weighted · graph-native
no join tables
HEX MODULES
6
domain · application
infrastructure isolated
STATE MACHINE
3
PENDING → ACCEPTED
or REJECTED
// hexagonal architecture + graph model
REST API infrastructure application domain connection state machine Strategy · 9 connection types virtual threads (Java 21) Neo4j 5 graph DB Testcontainers use cases · ports adapters · repositories · Spring Security · JWT
  • Chose Neo4j over relational to natively represent 9 weighted connection types — in a relational DB this would require join tables and recursive CTEs; in Neo4j it's a first-class traversal
  • Connection requests modeled as a state machine (PENDING → ACCEPTED/REJECTED) via the Strategy pattern for polymorphic handling per connection type — no if-chains
  • Structured across 6 hexagonal architecture modules — domain, application, infrastructure cleanly separated; Java 21 virtual threads for high-concurrency I/O
  • Domain logic validated against real Neo4j instances via Testcontainers — no mocks on the persistence boundary
github ↗ Java 21 · Neo4j 5 · Spring Boot 4 · Hexagonal Architecture · JUnit 5 · Testcontainers
## INTERESTS
→
Distributed systems
consistency models, replication lag, event-driven architecture
≈
Neural networks
backpropagation, gradient flow, architecture from first principles
∩
ML/backend intersection
vector search, embeddings, recommendations on the JVM
Σ
Algorithms & data structures
HNSW indexing, graph traversal, ANN retrieval

// stack

languages Java · TypeScript · C · Python · SQL
backend Spring Boot · WebFlux · Kafka · Node.js
data PostgreSQL · pgvector · Neo4j · Redis
infra Docker · GitHub Actions
## EXPERIENCE

WEG S.A.

Backend Developer — Industrial Learning Program · CentroWEG / SENAI

Industrial technical school integrated with WEG, one of the largest electric motor manufacturers in the world

Aug 2024 – Jul 2026
Jaraguá do Sul, BR
## GET IN TOUCH

// open to backend roles, distributed systems work, and interesting problems

EMAIL lucasismaeleckert@gmail.com → send a message GITHUB github.com/Luca5Eckert → see the code LINKEDIN lucas-ismael-eckert → connect