Mariano Gonzalez

Fast is the easy part. Here is why you can trust KPipe with your offsets.

Wed, 22 Jul 2026 00:00:00 +0000

KPipe, part 3 of 3: a simpler way to structure consumers · the first benchmarks · fast is the easy part

Last time I benchmarked KPipe I ended with a warning about my own numbers. Single runs moved 5 to 40 percent between iterations. There was no latency-percentile data. I told you to read the percentages as one-sigma indicators and not to quote the absolute throughput at anyone.

That was the honest thing to say at the time, and it was also a promissory note. This post is me paying it. The numbers here come from a quiesced machine - no browser, no IDE indexing, on mains power - with five JMH forks instead of one, the full workMicros sweep out to 100 ms per record, and latency percentiles alongside. The raw JSON and a dated markdown snapshot are committed in benchmarks/results/ as always. Where the last post had ±5-40% error bars, this one has ±0.1-6% on nearly every cell.

What did your mapper actually do? Now you can ask it.

Thu, 09 Jul 2026 00:00:00 +0000

Telescope, part 3 of 3: how it got built · why your mappings should not be strings · asking your mapper what it did

The setup

A field arrives null in production. The mapper between your entity and your DTO is the suspect, and now you get to answer a simple question: what did it actually map?

If the mapper is MapStruct, the answer lives in one place: the generated *MapperImpl.java under build/generated. You open it, you read the assignments, you diff what you read against what you meant. If the question is about a specific request — which values went in, which came out — generated source cannot answer it at all; you add a breakpoint or a log line, redeploy, and wait for the bug to happen again.

It is 2026. Why are your object mappings still strings?

Mon, 22 Jun 2026 00:00:00 +0000

Telescope, part 2 of 3: how it got built · why your mappings should not be strings · asking your mapper what it did

Update, July 2026. Since this went out, telescope grew the thing this post could not claim: mappers that are no longer black boxes. mapper.explain() returns the mapping structure as data, mapper.trace(input) shows the values flowing through, and flipping a log level makes every conversion narrate itself. The claims below also have receipts now: a feature-by-feature parity matrix covering 29 MapStruct features (none missing, every verdict with evidence) and a migration guide. A follow-up post will do those justice. The baseline moved too: telescope now requires Java 21.

From a Monocle port to one fluent type: how Telescope happened

Sat, 30 May 2026 00:00:00 +0000

Telescope is a Java deep-copy DSL for records and POJOs. You build a path through an immutable graph, then read it, write it, update it, traverse it, convert it, or thread an effect through it. No hand-written copy constructors. No mention of Iso, Lens, Prism, Affine, or Traversal anywhere in your code. The end-state is one method-ref chain on the runtime DSL, or one fluent chain on the generated navigator. Both bottom out at the same value:

Benchmarking KPipe against the parallel-Kafka libraries you would actually pick

Wed, 20 May 2026 00:00:00 +0000

KPipe, part 2 of 3: a simpler way to structure consumers · the first benchmarks · fast is the easy part

Update, July 2026. The two caveats at the bottom of this post - single-run variance of 5-40%, no latency-percentile data - are now closed. Part 3 re-runs everything on a quiesced box at five JMH forks with ±0.1-6% error bars and the full 0-100ms sweep, where the gap over Confluent Parallel Consumer widens to 41x, and adds the correctness half this post never touched: the at-least-once guarantee under jcstress. The numbers below are the first, rougher cut - read them as the start of the story, not the last word.

Kafka consumers get messy fast. KPipe is a simpler way to structure them.

Sun, 12 Apr 2026 00:00:00 +0000

Kafka consumers start simple.

Then they turn into tightly coupled, hard-to-test, side-effect-heavy code.

I built KPipe to fix that.

KPipe, part 1 of 3: a simpler way to structure consumers · the first benchmarks · fast is the easy part

GitHub repo

External write-ups

KPipe: A Modern, High-Performance Kafka Consumer in Java — Powered by Java 25 Features
Interesting links — May 2026 — mentions KPipe in the context of Kafka consumer libraries

What it looks like

The 80% path is a fluent facade. Five lines from main:

Supercharge SageMaker with Embeddings

Sat, 13 May 2023 15:50:53 -0500

Introduction

Deep Lake serves as a vector database that can integrate with Amazon SageMaker, allowing the storage of embeddings which are vector representations of data used in deep learning models. By leveraging Deep Lake’s vector database capabilities, developers can accelerate the training and deployment of their deep learning models. In this blog post, we will explore the details of this integration and how the use of vector databases can enhance the performance and accuracy of deep learning models.

Introduction to MLOps With SageMaker: Running your First LLM

Wed, 26 Apr 2023 17:27:40 -0500

Introduction

As the field of machine learning advances, it has become increasingly important for organizations to develop robust practices for managing their workflows. That’s where MLOps comes in - a set of best practices and tools for managing the entire lifecycle of machine learning models, from development to deployment and beyond.

In this blog post, we’ll delve into how MLOps practices can be leveraged to deploy an LLM in AWS SageMaker, using the popular Hugging Face Transformers library. We’ll cover everything from setting up an end-to-end pipeline for deploying a Large Language Model on SageMaker, to monitoring its performance.

Hello World

Fri, 07 Apr 2023 14:00:00 -0500

I’m a scala developer by trade, so let’s say hello in rust!

fn main() {
    println!("Hello World!");
}

About

Fri, 07 Apr 2023 13:58:29 -0500

I code by day and toy around with computers by night…