Forem: Matías Denda

What cave diving taught me about distributed systems

Matías Denda — Thu, 23 Apr 2026 16:32:38 +0000

What cave diving taught me about distributed systems

I've been building backend systems for 14 years. I've also spent a decent chunk of the last decade underwater, mostly in caves.

At some point I stopped being surprised by how often the two worlds rhyme. The deeper you go into either, the more you notice the same ideas showing up in different costumes. Here are a few that stuck with me.

You plan the dive, then you dive the plan

In open water, if something goes wrong, you go up. That's it. The surface is always there, a few kicks away, a guaranteed exit.

In a cave, there is no "up". There's a ceiling, and between you and air there's sometimes hundreds of meters of rock and a specific path you came in through. If something goes wrong at the end of a one-hour penetration, the solution is still one hour of swimming away — and you're the one who has to swim it, with whatever gas, light, and composure you have left.

So technical divers plan everything before getting in the water. Gas volumes for every phase, with reserves for the worst case and the worst case after that. Turn points. Decompression schedules. Equipment failures and who does what when they happen. Team positions, signals, lost-diver procedures. Murphy's law isn't a joke in this context — it's a design input.

The rule is: plan the dive, dive the plan. You don't improvise
underwater. You execute what you already decided on land, when your
brain had oxygen and no time pressure.

Software has the same trap, and most teams fall into it. "We'll figure it out in production" is the engineering equivalent of "we'll figure it out at 80 meters." Sometimes you get lucky. Often you don't.

The work that matters — capacity planning, failure mode analysis,
runbooks, rollback procedures, on-call rotations, dependency mapping — happens before the system is under load. Before the incident. Before anyone is stressed. Because the incident is not the time to start thinking. It's time to execute what you already thought through.

And just like diving, the planning doesn't eliminate failure. It just makes sure that when failure shows up, you've already met it on paper.

Failures cascade. Plan for the second failure, not the first.

The thing that kills divers isn't usually the first problem. It's the panic reaction to the first problem that causes the second one — and the second one is the one you weren't ready for.

Same in distributed systems. The database slowdown isn't what takes you down. It's the retry storm from 400 service instances hammering the recovering database that takes you down.

Good divers train for compound failures: light out and low on gas, lost line and silted visibility. Good systems are designed for compound failures too: circuit breakers, exponential backoff with jitter, bulkheads, and graceful degradation. Not because the first failure is rare, but because the second one, triggered by your response to the first, is where the real damage happens.

Turn pressure is a circuit breaker

Before a cave dive, you calculate your "turn pressure" — the tank pressure at which you stop going in and start coming out, regardless of how close you are to the thing you wanted to see. It's non-negotiable. You don't get to feel your way through it.

Circuit breakers work the same way. You pick a threshold in advance, when you're calm and have a clear head. And when the threshold trips, the system doesn't get to argue with it. It just turns around.

The hardest part of both is the same: accepting the limit you set for yourself when you were thinking clearly, even when the situation makes you want to push past it.

Checklists feel stupid until they save you

Every cave diver I respect uses a pre-dive checklist. Not because they forget things — but because under stress, everyone forgets things. The checklist is what your past, calm self leaves behind to protect your future, stressed self.

Runbooks are the same. The incident is not the time to remember the command. The deployment at 2 am is not the time to improvise the rollback procedure. Write it down when it's quiet. Read it when it's loud.

The real lesson

Both disciplines teach you the same uncomfortable thing: most disasters are built in advance, by people who assumed the happy path was the only path.

The habits that keep you alive in a cave are the same ones that keep systems running at 3 am on a Saturday. Redundancy, calm limits, planning for the compound failure, trusting your past self's checklist over your present self's instincts.

The costume is different. The physics of failure is the same.

If you're into either distributed systems or cave diving, I'd love to hear what overlaps you've noticed. Always surprising how many fields converge on the same answers.

One TUI for RabbitMQ, Kafka, and MQTT: why I built queuepeek

Matías Denda — Wed, 22 Apr 2026 13:00:00 +0000

The problem I was trying to solve

I work across a few projects that all talk to message brokers, but never the same one. Some services are on RabbitMQ. The data pipeline runs on Kafka. A handful of IoT integrations use MQTT. Normal stuff.

What wasn't normal was the amount of context-switching every time something went wrong in production. Three different web UIs, three different mental models, three different ways to peek at a message without accidentally consuming it.

The RabbitMQ Management UI is fine, but it's a web app — and half the time I'm already in a terminal next to the logs. Kafka UIs are a whole can of worms (every company seems to use a different one). MQTT doesn't really have a good "just let me see what's retained on this topic" tool for free.

So after one too many incidents where I wanted to diff two DLQ messages and ended up pasting JSON into an online diff tool, I started building what became queuepeek.

What it is

queuepeek is a terminal UI written in Rust (on top of ratatui) that speaks RabbitMQ, Kafka, and MQTT from the same interface. You launch it, pick a profile, drill down through queues/topics, and land on individual messages.

The entire thing is keyboard-driven and follows the same wizard flow regardless of the broker:

Profiles -> Queues/Topics -> Messages -> Message Detail

Esc always pops one level up. / always filters. ? always shows help contextual to where you are and which broker you're on.

No mouse. No tabs. No switching apps.

Design choices that paid off

Non-destructive peek

This was the whole point. A "queue inspector" that consumes messages while you're reading them is not an inspector — it's a silent bug waiting to happen.

For RabbitMQ, queuepeek uses the Management HTTP API's get endpoint with ack_requeue_true. You read, the message stays.
For Kafka, every read session spins up an ephemeral consumer with a unique group ID. You're not stealing offsets from anyone.
For MQTT, you're subscribing to a topic so it's inherently non-mutating, but retained message management has its own explicit screen with a clear "this will clear the retained payload" confirmation.

Sounds basic. A surprising number of tools don't do this.

Same keybindings, different brokers

Kafka doesn't have queues, it has topics. RabbitMQ has exchanges and bindings. MQTT has topic hierarchies. Under the hood these are very different beasts, but from the user's point of view, "show me what's in here" should feel the same.

The footer at the bottom of every screen dynamically filters shortcuts to the backend you're connected to — G:groups only shows on Kafka, X:topology only on RabbitMQ, H:retained only on MQTT. No dead keys, no "this doesn't work on your broker" errors.

Multi-select bulk ops

Checkboxes in a TUI sound fiddly, but they turned out to be one of the most useful features. Space toggles selection on the current message, then any operation you trigger (delete, copy, move, export) applies to all selected messages — streamed, not loaded into memory.

Want to delete 10,000 messages from a DLQ after confirming none of them match a pattern you care about? Filter, select all, delete. Done from the keyboard.

A few features I'm particularly happy with

Side-by-side message diff. Select two messages, press d, get a colored diff. Uses the similar crate. Embarrassingly useful for "why does this one message fail and the other succeed?"

Schema Registry integration. If you configure a Confluent-compatible Schema Registry URL, queuepeek auto-decodes Avro and raw Protobuf payloads using the Confluent wire format (magic byte 0x00 + 4-byte schema ID + body). Toggle raw/decoded with
s.

Real concurrent benchmarking. Press F5 on a queue to run a flood-publish benchmark with N worker threads (via std::thread::scope), rendering a live gauge and p50/p95/p99 latency percentiles at the end. Useful for capacity-planning conversations
that usually start with "how fast can this queue take?"

Webhook alerts. Configure a regex pattern in config.toml, point it at a webhook URL, and queuepeek polls every 30 seconds and POSTs on match (deduplicated by message hash so you don't spam yourself). Good for catching a specific error pattern appearing in a queue before it becomes an incident.

Payload templates with interpolation. Ctrl+T to save the current message, Ctrl+W to insert it. Supports variables like {{timestamp}}, {{uuid}}, {{random_int}}, {{counter}}, and {{env.VAR}} for anything you export in your shell.

DLQ reroute. RabbitMQ x-death headers get parsed and displayed, and L re-routes a message back to its original exchange. Mostly because I got tired of manually copy-pasting routing keys out of x-death.

Interesting implementation bits

A few things that weren't obvious going in:

ratatui + crossterm + mpsc channels is all you need for a responsive TUI. Background I/O (broker calls, file operations, webhook polling) runs in std::thread workers and posts results back through a channel that the event loop drains each tick.
No async runtime, no Tokio. The whole app feels instant.
Auto-refresh is dumb and works. Queue list refreshes every 5 seconds, message list every time tail mode is on. No WebSockets, no push. The Management API is cheap enough that polling is fine.
Scheduled messages persist to disk. ~/.config/queuepeek/scheduled.json with epoch seconds. If you schedule a publish and the app crashes or you close it, the schedule survives.
79 unit tests across filters, comparison, operations, schema decoding, and config. TUI logic is hard to test end-to-end, but the pure functions underneath are easy.

Try it

# From crates.io (needs cmake for librdkafka)
cargo install queuepeek

Or grab a prebuilt binary: https://github.com/matutetandil/queuepeek/releases

Supported platforms: macOS (ARM/Intel), Linux (x86), Windows (x86/ARM). Linux ARM builds need cargo install because cross-compiling librdkafka is its own adventure.

Minimal ~/.config/queuepeek/config.toml:

[profiles.local]
type     = "rabbitmq"
host     = "localhost"
port     = 15672
username = "guest"
password = "guest"
vhost    = "/"

Repo: https://github.com/matutetandil/queuepeek

Docs: /docs folder covers configuration, keyboard shortcuts, backends, and architecture.

What I'd love feedback on

It's a solo side project and I'm the main user. That means the keybindings reflect my own muscle memory, the defaults reflect my own workflows, and the rough edges are the ones I don't personally bump into.

If you spend time in any of these brokers and something feels off — a missing shortcut, a feature you'd expect, a decoding format I'm not handling — please open an issue. Especially on MQTT, which I use least.

MIT licensed. No telemetry. No signup. Just a binary that reads queues.

What actually happens when you `git merge --no-ff`

Matías Denda — Tue, 21 Apr 2026 14:48:28 +0000

Most developers use git merge without ever thinking about what's happening internally. Then one day they see --no-ff in a team's workflow documentation, Google it, read three Stack Overflow answers, and walk away with a vague sense that "it creates a merge commit or something."

This post is the version I wish I'd read earlier. Two diagrams, one clear distinction, and why it actually matters for your team.

The setup

You're on main. Your coworker merged their feature. You branched off, added two commits, and now it's time to merge your branch back. What happens next depends on one flag.

# You're here
git checkout main
git merge feature

Git has two ways to integrate your feature branch into main. The one it picks by default depends on whether the branches have diverged.

Case 1: Fast-forward (the default, when possible)

If main hasn't moved since you branched off, Git doesn't create a new commit. It just moves the main pointer forward to the tip of your feature branch.

That's it. No merge commit. The feature branch and main now point to the same commit. If you look at git log on main, it reads like D and E were always there. The branch effectively disappears from history.

Case 2: `--no-ff` (always create a merge commit)

With --no-ff, Git creates an explicit merge commit even when a fast-forward was possible:

M is a new commit whose parents are C (the previous tip of main) and E (the tip of feature). It has no code changes of its own — its diff is empty — but it records that these commits were integrated together at this point.

Why this distinction matters

The two histories above contain the same code. So does it matter? Yes, and here's where it bites real teams.

It matters for `git bisect`

git bisect helps you find which commit introduced a bug by doing a binary search through history. With fast-forward merges, the search descends into individual feature commits — you might land on a half-finished refactor where the bug is genuinely present but so is a broken test, making the bisect useless.

With --no-ff, you can run git bisect --first-parent and bisect merge commits only, treating each feature as an atomic unit. Found the regression? You know which feature to revert, not which arbitrary mid-feature commit to blame.

It matters for `git revert`

If you merged with --no-ff and need to roll back the feature, you revert the single merge commit:

git revert -m 1 <merge-commit-hash>

That undoes all of D and E in one go. With fast-forward, you'd need to revert each commit individually — or figure out which commits belonged to the feature in the first place.

It matters for reading history

git log --graph --first-parent main with --no-ff merges shows you a clean list of features integrated into main, one per line. Without merge commits, the log is a flat stream of every individual commit ever made. For a large team, the difference is between "I can see what shipped last week" and "good luck."

What GitHub and GitLab do

When you click "Merge pull request" on GitHub or GitLab, they default to creating a merge commit (--no-ff behavior). The "Rebase and merge" and "Squash and merge" options exist too, but the default merge commit exists precisely because of the benefits above.

This is why teams that use the GitHub/GitLab UI religiously often have cleaner history than teams that merge locally on the command line — the UI forces a pattern that the command line leaves optional.

When fast-forward is fine

For throwaway branches, personal experiments, or single-commit fixes where the commit already tells the whole story, fast-forward is perfectly appropriate. The rule of thumb I use:

Single commit fix → fast-forward is fine
Feature branch with 2+ commits → --no-ff preserves the grouping
Release branch merge → always --no-ff
Hotfix branch merge → always --no-ff (you want revertability)

Making it a team default

If you want the team to use --no-ff consistently, either set it at the repo level:

git config --global merge.ff false

Or — better — require it via branch protection rules on your hosting platform. That way nobody's local config can bypass it.

This post is adapted from a chapter of Git in Depth: From Solo Developer to Engineering Teams, a 658-page book I just released on Git for working developers — from day-to-day tools to CI/CD, branching strategies, and Git at organizational scale. Launch price $29 with code EARLYBIRD (first 100 copies).

Next week: git worktree — the stash replacement nobody teaches you.

Automatic Node.js Version Switching Across Projects

Matías Denda — Fri, 07 Nov 2025 21:21:15 +0000

The Challenge

Modern JavaScript development often involves working on multiple projects simultaneously. Each project may require a different Node.js version:

Legacy project: Node 14
Production app: Node 18 LTS
New experimental project: Node 20

Manually switching versions between projects adds friction to your workflow. You need to remember which version each project uses and run the appropriate commands when switching contexts.

What is AutoNode?

AutoNode is a CLI tool that automatically detects and switches to the correct Node.js version when you navigate between projects. It works seamlessly with your existing version manager (nvm, nvs, or Volta).

Key features:

🔍 Automatic version detection from multiple sources
⚡ Zero runtime dependencies (single native binary)
🔄 Works with your existing version manager
🌍 Cross-platform (macOS, Linux, Windows)
📦 Under 6MB with everything included

How It Works

Version Detection

AutoNode reads version requirements from multiple sources (in priority order):

.nvmrc - Standard nvm configuration file
.node-version - Alternative version file format
package.json - Reads engines.node field
Dockerfile - Parses FROM node:X declarations

This multi-source approach ensures compatibility with different project conventions.

Shell Integration

When you cd into a project directory, AutoNode:

Detects the required Node.js version
Checks which version manager you have installed
Switches to the appropriate version automatically

The integration works through a shell hook similar to other developer tools like direnv or starship.

Installation

One-line install:

  curl -fsSL https://raw.githubusercontent.com/matutetandil/autonode/main/install.sh | bash

The installer will:

Detect your platform and architecture
Download the appropriate binary
Install to a standard location
Configure shell integration for bash/zsh/fish

Manual Commands

You can also use AutoNode manually:

Check detected version without switching

autonode --check

Force reinstall detected version

autonode --force

Update AutoNode itself

  autonode update

Real-World Use Cases

Development Teams

Ensure all team members use consistent Node.js versions across projects without manual intervention.

CI/CD Pipelines

Automatically use the correct Node version in build scripts without hardcoding version numbers.

Monorepo Management

Different packages in a monorepo can specify different Node requirements, and AutoNode handles transitions seamlessly.

Docker Development

Parse Node versions directly from Dockerfiles to match your local environment with production.

Compatibility

Operating Systems:

macOS (Intel & Apple Silicon)
Linux (AMD64 & ARM64)
Windows (AMD64)

Version Managers:

nvm (Node Version Manager)
nvs (Node Version Switcher)
Volta

Shells:

bash
zsh
fish

Roadmap

Planned improvements:

Additional version manager support (fnm, asdf)
Configuration file for custom behavior
Shell completion scripts
Package manager distribution (Homebrew, apt)
Pre-commit hooks integration
CI/CD action/workflow templates

Contributing

AutoNode is open source and welcomes contributions. Whether it's:

Bug reports and fixes
New version detector implementations
Version manager integrations
Documentation improvements
Feature requests

Check out the https://github.com/matutetandil/autonode to get involved.

Try It Out

Installation:

curl -fsSL https://raw.githubusercontent.com/matutetandil/autonode/main/install.sh | bash

Quick test:

  mkdir test-project && cd test-project
  echo "18.17.0" > .nvmrc
  # AutoNode switches automatically
  node --version

Feedback Wanted:

I'm actively looking for feedback on:

Does it work reliably with your setup?
Any edge cases in version detection?
Performance in large monorepos?
Installation experience on different platforms?

Feel free to open an issue or start a discussion on GitHub!

Resources

GitHub Repository: https://github.com/matutetandil/autonode
Documentation: Full setup and usage guide in the README
Installation Script: Direct download and shell integration
Releases: Pre-built binaries for all platforms

AutoNode aims to simplify Node.js version management across projects. If you find it useful or have suggestions, I'd love to hear from you!

Forem: Matías Denda

What cave diving taught me about distributed systems

What cave diving taught me about distributed systems

You plan the dive, then you dive the plan

Failures cascade. Plan for the second failure, not the first.

Turn pressure is a circuit breaker

Checklists feel stupid until they save you

The real lesson

One TUI for RabbitMQ, Kafka, and MQTT: why I built queuepeek

The problem I was trying to solve

What it is

Design choices that paid off

Non-destructive peek

Same keybindings, different brokers

Multi-select bulk ops

A few features I'm particularly happy with

Interesting implementation bits

Try it

What actually happens when you `git merge --no-ff`

The setup

Case 1: Fast-forward (the default, when possible)

Case 2: --no-ff (always create a merge commit)

Why this distinction matters

It matters for git bisect

It matters for git revert

It matters for reading history

What GitHub and GitLab do

When fast-forward is fine

Making it a team default

Automatic Node.js Version Switching Across Projects

The Challenge

What is AutoNode?

How It Works

Version Detection

Shell Integration

Installation

Manual Commands

Check detected version without switching

Force reinstall detected version

Update AutoNode itself

Real-World Use Cases

Development Teams

CI/CD Pipelines

Monorepo Management

Docker Development

Compatibility

Roadmap

Try It Out

Installation:

Quick test:

Feedback Wanted:

Case 2: `--no-ff` (always create a merge commit)

It matters for `git bisect`

It matters for `git revert`