DEV Community: Kauan Oliveira

Agentic Workflow" the death of traditional Microservices Architecture?

Kauan Oliveira — Wed, 29 Apr 2026 07:58:35 +0000

Most of us spent our careers building deterministic pipelines: Request -> Auth -> Logic -> Database -> Response. However, with the rise of AI Agents that can "reason" and call tools (Function Calling), the way we structure our backends is changing. We are moving from rigid API flows to dynamic, agentic workflows where the LLM decides which microservice to hit next.

The Architectural Shift:
In my recent projects involving Ruby and Go, I’ve started thinking: instead of building an API for a frontend, should we be building APIs specifically for AI Agents? This means:

Stricter OpenAPI specs: If the AI doesn't understand your schema, the system fails.

Resilience is key: A Go-Gateway with aggressive rate-limiting is more important than ever when an AI agent can trigger 1,000 requests in a loop by mistake.

State Management: How do we track state when the execution path is no longer hardcoded?

The Question for the Community:
Are you already designing "Agent-friendly" APIs?

Does Clean Architecture (SOLID) help or hinder when the "client" of your code is an LLM instead of a human developer?

How do you handle security when an AI has the autonomy to call multiple backend functions?

I’m exploring these patterns in my latest GitHub modules—integrating resilient gateways with dynamic execution. Let's talk about the future of the backend!

AI-Driven Infrastructure: Are we ready for the shift from General Purpose to AI-Specific Hardware?

Kauan Oliveira — Wed, 29 Apr 2026 07:55:43 +0000

The buzz around LLMs is everywhere, but as systems engineers, we need to talk about the "elephant in the server room": the hardware bottleneck.

For decades, we’ve optimized for general-purpose CPUs. But now, with the surge of AI, the architecture of our data centers is shifting towards GPUs, TPUs, and specialized NPU clusters. This isn't just a "hardware upgrade"; it’s a fundamental change in how we design software.

The Engineering Challenges:
Memory Wall: While AI models need massive bandwidth, our traditional memory architectures are struggling to keep up.

Energy Density: We are moving from 10kW per rack to 50kW or even 100kW. How does this impact our choice of languages (like C++ or Rust) for the orchestration layer to minimize energy waste?

Deterministic Latency: In systems like my telemetry engine, adding an AI inference step can destroy microsecond SLAs. How do we integrate "probabilistic" AI into "deterministic" systems?

Let’s Discuss:
Do you think software engineers should start learning about CUDA or Triton, or should we stay at the abstraction layer?

How are you handling the latency added by AI inference in your backend pipelines?

Is the future of "Cloud Native" actually "AI Native"?

The Polyglot Architect: Choosing Between .NET 9, Go, and Rust for High-Throughput Systems

Kauan Oliveira — Wed, 29 Apr 2026 07:54:11 +0000

We often hear the advice: "Master one language." But in modern systems engineering, being stack-agnostic is becoming a superpower.

I’ve spent the last few months building different modules for a telemetry and stream ecosystem, and the biggest lesson was realizing that the "best" language depends entirely on which part of the hardware you are trying to optimize.

The Breakdown of my Ecosystem:
Go (The Gateway): I used Go for the entry point. Why? Because Goroutines and the built-in race detector make it the perfect tool for resilient API Gateways with Circuit Breakers and Rate Limiting.

C# (.NET 9 - The Stream Engine): For real-time data flow, .NET 9's Channels and Span provide an incredible balance between memory safety and high throughput. It handles massive streams without the garbage collector jitter we used to see in older versions.

Rust/C++ (The Core): When I needed SIMD instructions and lock-free data structures for telemetry, I went to the metal. No runtime, no overhead.

The Engineering Trade-off
The real challenge isn't writing the code in one language; it's the Governance. How do you ensure that your Ruby orchestrator, your Go gateway, and your C++ engine all follow the same Clean Architecture principles?

I’ve been applying Contract-Driven Development to ensure that even though the languages change, the architectural integrity remains.

Let’s discuss:

In your project, do you prefer a "Mono-stack" for easier maintenance or a "Multi-stack" for specialized performance?

How do you handle "Context Switching" as a developer when jumping between Rust's memory management and Go's simplicity?

Is Clean Architecture (SOLID) still viable when you are pushing for microsecond performance?

I've documented these trade-offs in my projects:
https://github.com/kauandias747474-hue

Bypassing the Python GIL: Achieving Microsecond Latency with Shared Memory and C++ Engines

Kauan Oliveira — Wed, 29 Apr 2026 07:52:41 +0000

High-level languages like Python are incredible for developer productivity, but when you hit the wall of the Global Interpreter Lock (GIL) in mission-critical systems, things get messy.

Recently, I’ve been working on an infrastructure ecosystem (UHI) where I needed to orchestrate heavy data workloads using Python without sacrificing the raw performance of the hardware. The solution? Stop fighting the GIL and start bypassing it.

The Architecture: Shared Memory & Zero-Copy
Instead of traditional IPC like Sockets or JSON over HTTP—which introduce massive serialization overhead—I implemented a Zero-Copy Data Pipeline.

The strategy:

C++ Telemetry Engine: Handles the heavy lifting, SIMD optimizations, and raw data processing.

Shared Memory (mmap): We map a memory segment directly into the address space of both the C++ engine and the Python orchestrator.

Binary Serialization: Using C-style structs to ensure that what C++ writes, Python reads instantly with zero translation.

Why this matters
In industrial automation or HFT (High-Frequency Trading) scenarios, a 10ms delay is an eternity. By using CPU Pinning and memory barriers, I managed to keep the latency deterministic even while using Python as the "control plane".

I’d love to hear your thoughts:

Have you ever integrated a high-level language with a C/C++ core?

What’s your take on using Shared Memory vs. Lock-free queues for inter-process communication?

At what point do you decide that Python isn't enough and move the entire logic to the "metal"?

Check out my implementation logic here: https://github.com/kauandias747474-hue/Python-Ultra-Hardened-Infrastructure-UHI-

Building a Bulletproof Tax Engine with Modern Java: Strategy, Parallelism, and Precision

Kauan Oliveira — Thu, 12 Mar 2026 10:36:58 +0000

In the financial world, "close enough" isn't good enough. When building a core engine for tax calculations, you face three main enemies: rounding errors, volatile business rules, and scaling bottlenecks.

I recently developed a Tax Strategy Engine as a technical showcase to demonstrate how modern Java (17+) features can solve these challenges elegantly. This PoC isn't just about calculating percentages; it’s about Defensive Engineering and Software Governance.

The 4 Pillars of the Architecture

The Contract (Strategy Pattern)
Tax laws change frequently. To keep the core engine agnostic, I implemented the Strategy Pattern. The engine doesn't know what it is calculating; it only knows it has a contract to fulfill.

Benefit: Allows adding new taxes (VAT, Sales Tax, GST, ICMS) without changing a single line of the main engine code, honoring the Open/Closed Principle.

The Shield (Banking Precision)
Using double or float for money is a major error in financial development. Binary floating-point representation leads to rounding inaccuracies.

The Solution: Exhaustive use of BigDecimal with explicit RoundingMode.HALF_UP.

The Result: Cent-by-cent integrity throughout the entire pipeline.

The Sentry (Fail-Fast and Immutability)
Data corruption often happens when objects are modified across threads or initialized with invalid states.

Java Records: I used record types to ensure data is immutable by default and thread-safe.

Fail-Fast Validation: Using a rigorous constructor check, the system prevents the creation of objects with negative or null values, catching errors at the entry point and preventing the propagation of corrupt data.

The Engine (Parallel Processing)
Financial reports can involve millions of rows.

Parallel Streams: The engine utilizes parallelStream() to distribute tasks across multiple CPU cores, ensuring high-throughput performance.

Latency Simulation: By implementing TimeUnit sleeps, I demonstrated how the multi-threaded approach maintains performance even when individual operations have simulated latency.

Technologies and Concepts Applied

Modern Java: Records (17+), Functional Interfaces, Lambdas, Streams API
Architecture: SOLID Principles, Strategy Design Pattern, Defensive Engineering
Performance: Parallelism, Multithreading, Concurrent API
I/O and I18n: Java NIO (Files/Paths), Internationalization (Locale/NumberFormat)
Security: Privacy by Design (Data Anonymization/Masking)

Engineering a Reliable Autoloader: The Logic Behind the Test

Kauan Oliveira — Mon, 09 Mar 2026 15:26:11 +0000

When building a custom engine, the first thing you need is a way to handle classes automatically. But how do you ensure your mapping logic won't fail in production?

The answer lies in a specific integration test: the AutoLoaderTest.php.

The Core Logic: "Silent Instantiation"
The goal of this code is to prove that the Segment Algorithm is working. Instead of manually requiring files, the engine must intercept a class call and translate it into a physical path.

What this code validates:
Namespace-to-Path Mapping: It confirms that a call like new App\Controller\User() correctly points to src/Controller/User.php.

Case Sensitivity: It checks if the class name matches the file name exactly. This is vital for cross-platform compatibility (moving code from Windows to Linux).

Recursive Discovery: It proves that the engine can navigate through deep subdirectories (e.g., App\Core\Security\Providers) using explode and implode logic to resolve the path.

Why this test is essential:
Scalability: It ensures the engine can handle hundreds of classes without manual configuration.

Decoupling: The developer only needs to know the class name, while the engine handles the file system.

Zero-Error Foundation: By testing the autoloader first, you ensure the very heart of the system is stable before writing any business logic.

Testing the infrastructure is what ensures a professional, production-ready backend

How I Built a Resilient Idempotency Engine for Financial Transactions (Vanilla Java)

Kauan Oliveira — Sun, 08 Mar 2026 17:38:49 +0000

How I Built a Thread-Safe Idempotency Engine for High-Resilience Systems

Building robust backend systems means preparing for the worst-case scenario. One of the most common issues in financial or critical systems is the Duplicate Request problem. A user clicks a button twice, a network retry triggers a second call, and suddenly, you have a double-spending issue.

To solve this, I developed a lightweight Idempotency Engine in Java, focusing on a "Vanilla-First" approach to maintain total control over memory and performance.

⚙️ The Architecture

The engine acts as a State Interceptor. It sits between the incoming request and the business logic. If a request with the same unique key arrives, the engine knows exactly how to handle it based on its previous state.

Key Features:

LRU Cache (Least Recently Used): I used a synchronized cache to manage transaction records in memory. This prevents Memory Overflow by discarding the oldest entries under heavy load.
Thread-Safety: By using Collections.synchronizedMap, the engine is protected against Race Conditions, which is essential for multi-threaded environments.
Anti-Fraud Window: It includes an automatic 30-second preventive block for identical attempts to mitigate replay attacks.
Failure Resilience: The engine distinguishes between successful and failed transactions. If an operation fails, it allows an immediate retry, clearing the error trail to ensure the flow continues.

🛡️ Layers of Defense

Challenge	Defense Mechanism	Goal
Double Spending	Unique Idempotency Key	Prevent duplicate charges in real-time.
Replay Attack	Timestamp Validation	Block repeated packets captured by third parties.
Race Condition	Memory Synchronization	Prevent parallel requests from bypassing validations.
Memory Overflow	LRU Eviction Policy	Maintain server stability under heavy load.

🚀 Why Vanilla Java?

Building this from scratch allowed me to implement a custom Registration object to encapsulate transaction metadata (values, status, and timing) without the overhead of heavy frameworks. This is about deep understanding of system engineering and resilience.

Check out the source code:

👉 https://github.com/kauandias747474-hue/Java-Backend-Architecture/tree/main/src/main/java/org/engine/core/idempotency