DEV Community

Cover image for The Architect's Paradox: From a 106 Fan-Out "God Object" to Sovereign AI in Java 25
Eber Cruz Fararoni
Eber Cruz Fararoni

Posted on

The Architect's Paradox: From a 106 Fan-Out "God Object" to Sovereign AI in Java 25

As a Staff Engineer with over 11 years in mission-critical banking systems (HSBC, Santander), you’d think I’ve seen it all. When I began building the Fararoni ecosystem—a Java 25-based infrastructure for Sovereign AI—I had a clear vision: low-latency agentic orchestration, NATS JetStream, and sub-microsecond interrupt cycles. I had the patterns in my head, but I didn't have the diagram on paper.

Complex dependency graph showing a technical 'Big Ball of Mud' with a Fan-out of 106. It features multiple columns of modules interconnected by a dense, chaotic web of orange lines, representing the high architectural coupling in the initial version of the Fararoni ecosystem.
The Knot: When Speed Becomes a Liability
In my obsession with "touching the metal" of Project Panama (FFM) and Virtual Threads, I built a high-performance engine trapped inside a "Big Ball of Mud." When I finally ran a metrics audit, the reality check was brutal: my FararoniCore class had a Fan-Out of 106. I was micro-managing 106 components from a single orchestrator. I had created a "God Object" in a system meant to preach decentralization.

The "Limitations" of the Cutting Edge
While Java 25 is a masterpiece, the friction between high-level abstraction and native performance (Panama/Loom) is where the real architecture happens. If you don't design clean boundaries, you hit operational ceilings:

Carrier Thread Pinning: In high-contention scenarios with native calls, Virtual Threads can block the carrier, killing the very scalability you seek.

Arena Lifecycles: Managing memory in Panama isn't hard; managing it across 106 coupled components without leaks is impossible.

Observability: Debugging 10,000+ virtual threads in a "Ball of Mud" is a nightmare.

The Re-engineering: The Road to Rome
They say "All roads lead to Rome," referring to the Milliarium Aureum in the Roman Forum. In software, there are multiple paths to success, but sustainability requires a map. I chose to pause and dismantle the chaos:

Domain Evacuation: Moving state to immutable Records.

Bounded Contexts: Refactoring 68 flat directories into 7 clean "neighborhoods."

The NATS Decoupling: Moving from direct calls to an event-driven bus. The Core no longer "pushes" data; it emits events.

Ports & Adapters: Implementing Hexagonal Architecture so that switching a module is like plugging in a cable, not rewriting the heart of the system.

A clean Hexagonal Architecture diagram for the Fararoni Sovereign AI ecosystem. The layout shows a clear separation of concerns: Input Drivers (Infrastructure), a Core Hexagon containing Sovereign Logic modules (AgentLife, Cognitive, Orchestrator, Security), Driven Output Adapters (Observability and NATS-based Transport), and a shared Foundation layer.
Conclusion: The Resilient Architect
Quality isn't just about the lines you write, but the ones you manage to decouple. I didn't settle for "it works." I obsessed over making it Sovereign and maintainable. Being vulnerable as an architect means admitting the code beat you for a day; being resilient means winning the war for design.

About the Author

Eber Cruz Fararoni is a software engineer with a decade of experience designing backend infrastructure and distributed systems.

Currently focused on AI-assisted software engineering, deterministic guardrails, and hybrid kernel architectures for secure LLM execution.

This article documents the architecture behind C-FARARONI, an experimental ecosystem for technological

sovereignty and secure local AI model execution.

LinkedIn · GitHub · ebercruz.com


Top comments (0)