The unit of this architecture is the service itself. Each microservice owns a single domain, talks to its own dedicated database, and is the only thing allowed to write to that data. Externally, it has two communication modes: it publishes and subscribes to events through a Pub/Sub broker — Google Pub/Sub, Apache Kafka, and RabbitMQ are the usual suspects — for anything that can tolerate asynchrony, and exposes REST endpoints for the narrow set of queries that need a synchronous, low-latency answer. There’s also a third pattern worth calling out: a service can accept a command over HTTP and, rather than processing it inline, immediately publish the payload to a topic it subscribes to itself. The HTTP call returns quickly, and the actual work happens asynchronously through the normal event pipeline. This keeps the API surface thin and responsive while letting the processing logic live entirely within the event-driven flow.

This decoupling is what makes the system actually debuggable. When something goes wrong in a synchronous HTTP chain, the failure is often masked or transformed by the time it surfaces. In an event-driven system, the failure is contained at the subscriber that couldn’t process the message. When a subscriber throws an exception, instead of silently dropping the message or retrying indefinitely, it publishes to a central DLQ topic with two things attached: the original payload and the full stack trace. Both matter. That’s the key insight behind the Centralized Dead Letter Queue. The payload tells you exactly what the service was trying to process; the stack trace tells you exactly where and why it failed. There’s no ambiguity, no reproducing a request from memory.

From there the workflow is straightforward. A dedicated consumer service reads from the general DLQ topic, stores the messages in a file bucket or database, and surfaces them in a UI organized by producer service, topic, error message and date. An engineer investigating a failure opens the DLQ UI, finds the failing messages for the services he owns, reads the stack trace, and has everything needed to diagnose the problem — often without touching a log aggregator at all. Once a fix is deployed, they can replay the original message with its exact payload directly from the UI, confirming the fix and recovering any affected state in one step. If the message is simply invalid and not worth reprocessing, they delete it. The whole loop — detection, diagnosis, fix, recovery — is something a single engineer can close without a war room or a support ticket chain. That’s not just a better developer experience. It’s a structural property of the architecture.

What makes this actually work — and not just a nice-sounding value that collapses under pressure — is the infrastructure underneath it. The observability stack at Nubank is genuinely world-class. Distributed tracing, structured logs, stacktraces linked to kafka payloads and the ability to replay failed messages on demand, dashboards that correlate events across services with enough precision that you can usually pinpoint a failure in minutes rather than hours. Pair that with CI/CD pipelines that let you go from a fix to production without a deployment ceremony, and troubleshooting stops feeling like a disruption to your day. It becomes a loop you can close quickly and cleanly. The investment in tooling is what gives engineers the confidence to own incidents without needing to ask for permission or wait for a war room.

The deeper thing this reflects is trust. Nubank trusts engineers to self-organize around problems, create their own tickets, and report back at standup with status rather than waiting to be assigned. That’s a small cultural detail with big implications — it means the person closest to the code is also the person making the call on priority. No handoff, no delay, no context lost in translation. We’d often walk into a standup having already found the issue, opened the ticket, shipped the fix, and confirmed it in production. The DLQ was back to zero before anyone formally asked about it. That’s the kind of reliability culture that’s hard to document in a process guide because it’s not really a process — it’s just what good engineering looks like when you trust the people doing it.

In object-oriented languages I’ve worked with, solving a backend problem comes with a ritual. You need an interface so you can test it. You need a class to implement it. You need a constructor, probably a factory, getters and setters for the fields, and somewhere in there a design pattern that wraps the whole thing in just the right level of abstraction so it doesn’t feel hacky. None of this is wrong — it’s the grammar of the language, and experienced engineers use it well. But it is ceremony. A significant chunk of the code you write isn’t the logic of the problem; it’s the scaffolding the language requires to hold the logic. In Clojure, most of that scaffolding disappears. You write a function that takes data and returns data. If the function gets complicated, you break it into smaller ones. If you need polymorphism, multimethods let you dispatch on anything — not just type. If you need to manage stateful components like a database connection or a message queue, Stuart Sierra’s component pattern handles lifecycle cleanly without turning your codebase into an inheritance diagram.

To be fair, none of this means OOP is overengineered or that people who use it are doing it wrong. The boilerplate exists for good reasons — encapsulation, extensibility, the ability to reason about boundaries. Languages like C# and Java have gotten genuinely good at managing complexity at scale. The difference is that in Clojure, the higher-level abstractions are already there by default. Data is immutable. Functions are first-class. The language nudges you toward simplicity rather than requiring discipline to achieve it. What used to take an interface, two implementations, and a factory now takes a map and a function. The core logic — the part that actually solves the problem — is exposed rather than buried.

After a year of this, going back to a class-heavy codebase feels a bit like snowboarding — you spend a good chunk of the morning renting boots, adjusting bindings, layering up, and getting to the top of the mountain before you actually get to ride down. And riding down is great, genuinely worth it. Just a little bit slower before the fun begins. I don’t think Clojure is the right tool for everything, and I still respect what well-crafted OOP looks like. But for backend systems where the work is fundamentally about transforming data — taking something in, doing something to it, producing something out — functional programming with Clojure maps almost perfectly to the shape of the problem. The code ends up looking a lot like the logic, and that’s a relief.

What is the Levenshtein distance?

The Levenshtein distance is a metric that measures the difference between two strings — specifically, the minimum number of single-character edits (insertions, deletions, substitutions) required to change one string into the other. For example, the distance between "books" and "back" is three:

books -> baoks  (substitution: "o" → "a")
baoks -> backs  (substitution: "o" → "c")
backs -> back   (deletion of "s")

Phil Factor writes about the edit distance and gives an implementation in MS SQL Server’s T-SQL in his post String Comparisons in SQL: Edit Distance and the Levenshtein algorithm. Other databases ship with a built-in: LEVENSHTEIN in PostgreSQL, EDIT_DISTANCE_SIMILARITY in Oracle, and EDITDIST3 in SQLite.

This is very useful when trying to identify that 931 Main St is the “same” as 931 Main Street — a common problem in any system that stores client information. The trick is to convert the raw distance into a ratio based on the length of the longer string, giving you a percentage of similarity. In my experience, a ratio below 50% works well as a threshold.

An example in PostgreSQL

Say we have this table:

CREATE TABLE Addresses(
  LINE1 text,
  LINE2 text
);

With sample data where each row holds two versions of the same address — similar enough for a human, but not for LIKE:

INSERT INTO Addresses (LINE1, LINE2) VALUES
  ('9128 LEEWARD CIR, INDIANAPOLIS, IN',      '9128 Leeward Circle, Indianapolis, IN'),
  ('101 OCEAN LANE DRIVE, KEY BISCAYNE, FL',  '101 Ocean Lane Drive Unit 1010, Key Biscayne, FL'),
  ('9301 EVERGREEN DRIVE, PARMA, OH',          '9301 Evergreen Dr, Parma, OH'),
  ('1817 BERTRAND DR, LAFAYETTE, LA',          '2924 Polo Ridge Ct, Charlotte, NC'),
  ('201 E 87TH ST, NEW YORK, NY',              '201 E 87th Street 3E, New York, NY'),
  ('799 CARRIGAN AVE, OVIEDO, FL',             '799 Carrigan Avenue, Oviedo, FL'),
  ('4014 CADDIE DRIVE, ACWORTH, GA',           '10617 WEYBRIDGE DR, TAMPA, FL');

Now use LEVENSHTEIN to calculate a similarity ratio:

SELECT
  Line1,
  Line2,
  LEVENSHTEIN(UPPER(line1), UPPER(line2)) AS distance,
  LEVENSHTEIN(UPPER(line1), UPPER(line2))::decimal
    / GREATEST(length(line1), length(line2)) AS ratio
FROM Addresses;

Rows 4 and 7 are clearly different addresses (ratio > 0.5). Adding a WHERE clause filters them out:

SELECT
  Line1,
  Line2,
  LEVENSHTEIN(UPPER(line1), UPPER(line2)) AS distance,
  LEVENSHTEIN(UPPER(line1), UPPER(line2))::decimal
    / GREATEST(length(line1), length(line2)) AS ratio
FROM Addresses
WHERE LEVENSHTEIN(UPPER(line1), UPPER(line2))::decimal
        / GREATEST(length(line1), length(line2)) < 0.5;

You can play with this yourself in SqlFiddle.

Learning that way in such a short time means going from beginner to master in 24 hours, 7 days, or a month. That’s practically impossible unless you already have deep knowledge in a discipline that heavily overlaps with the one you’re trying to learn.

Through my own experience and with the help of colleagues and mentors, I’ve come to see that there are four broad stages every programmer goes through on the way to advanced software engineering knowledge: Novice, Beginner, Intermediate, and Advanced. These apply to the professional world and are based on the Dreyfus model of skill acquisition, originally proposed at UC Berkeley for the U.S. Air Force Office of Research.

1. Novice. The person has started learning the fundamentals and has a lot of room to grow. They’re picking up core concepts — inheritance, encapsulation, abstraction, polymorphism — mostly in the abstract, without much depth yet. They can’t complete tasks on their own. Using a hunting analogy: they know a lion exists and that it’s dangerous. But the lion would hunt them, not the other way around.

2. Beginner. They have enough skills to succeed in their role and genuinely understand software engineering concepts. Their knowledge goes deeper into the specific technology they use — things like LINQ, generics, and extension methods in C#. They can solve problems without help. In the analogy: they can hunt lions, but with guides who lead them to the pride and warn them when one charges — and who might step in themselves if the lion is particularly nasty.

3. Intermediate. They know which technique to use and when. They can rationalize why things work the way they do, and apply concepts across different contexts — understanding not just how, but why certain patterns work sometimes and fail other times. They’ve mastered their tools (IDEs, languages, RDBMS) and can handle ambiguity. They know advanced universal concepts: composition over inheritance, design patterns, asynchronous programming, unit testing. In the analogy: they hunt lions alone, in record time, and can coach beginners. If someone asks for a coat, they already know you have to go hunt something first.

4. Advanced. They can do this in their sleep — and have probably debugged something in a dream. They have a solid, internalized understanding of programming and take an active role in leading and teaching others. They understand techniques that transcend their niche: AOP, functional programming, software architecture, when and how to apply each. They define the approach, not just follow it. In the analogy: they train other hunters, know to move downwind so the lion doesn’t smell them, and invent new techniques. They’ll also take down the occasional bear, even though lions are their specialty.

After these four, there’s a fifth stage that very few people pursue — and that most managers don’t actively push for, since it actually lowers raw productivity. This stage is about research and extending known techniques to solve entirely new classes of problems. In the analogy: this person hunts lions, tigers, bears, and even the Yeti. They give weekend talks about having bagged five Yetis on time and under budget, and their closing slide explains why Gantt charts aren’t the right tool for Yeti hunting.

A newly graduated engineer typically lands at Beginner, though it’s not guaranteed — some stay at Novice even after graduating. Research suggests productivity actually dips when moving from Beginner to Intermediate, then rises sharply through Intermediate and Advanced. The jump from Beginner to Intermediate takes roughly 6–18 months; Intermediate to Advanced takes another 18–36 months. Getting there is not automatic — it depends on the projects you work on, your enthusiasm, and the mentors you find along the way.

A New Opportunity

Switching jobs to join Nearsoft gave me a fantastic opportunity to explore the latest developments in the .NET ecosystem. As a long-time fan of C# and its evolving features, I hadn’t been working with the absolute latest versions, but I had been reading up and building exercise projects.

At Nearsoft, I began diving into .NET Core 2 to see how I could implement familiar techniques. What immediately stood out to me was Aspect-Oriented Programming (AOP).

What is Aspect-Oriented Programming?

AOP is a programming paradigm aimed at increasing modularity by separating cross-cutting concerns from your core business logic. Behaviors that your application needs to perform in multiple places—such as logging, transaction handling, or caching—can be added seamlessly without cluttering your actual code.

For the examples below, we will use Autofac and DynamicProxy from the Castle project.

You will need the .NET Core SDK installed on your system, and optionally, Visual Studio (VS). On a Mac, you can easily install them using Homebrew:

macbook:aop cblanco$ brew install --cask dotnet-sdk
macbook:aop cblanco$ brew install --cask visual-studio

Setting Up a New Project

With .NET installed on your machine, let’s create a new console project. Open up a terminal window and run the following command:

macbook:dotnet cblanco$ dotnet new console -n aop

I’ll be using Visual Studio for Mac for this post, so let’s open the solution there. cd into the project’s folder, run the solution, and check the console output:

macbook:aop cblanco$ dotnet run
Hello World!

Using Autofac and DynamicProxy

So far, so good. Now let’s implement AOP.

First, add the Autofac.Extras.DynamicProxy NuGet package to your solution. This package automatically brings in Autofac and Castle.Core as dependencies.

Autofac.Extras.DynamicProxy enables the interception of method calls on Autofac components. This matches the goal of AOP perfectly.

There are four steps to implementing interception using DynamicProxy:

1. Create Interceptors.
2. Register Interceptors with Autofac.
3. Enable Interception on Types.
4. Associate Interceptors with Types to be Intercepted.

We will implement two interceptors: one for logging and one for caching. Then, we will combine them to see how the whole system works together.

Step 1: Implementing a Logger

The first step is to implement the Castle.DynamicProxy.IInterceptor interface. This interceptor will log which method is being executed, the parameter values it receives, and its total execution time.

public class Logger : IInterceptor
{
    private readonly TextWriter _writer;

    public Logger(TextWriter writer)
    {
        _writer = writer ?? throw new ArgumentNullException(nameof(writer));
    }

    public void Intercept(IInvocation invocation)
    {
        var name = $"{invocation.Method.DeclaringType}.{invocation.Method.Name}";
        var args = string.Join(", ", invocation.Arguments.Select(a => (a ?? "").ToString()));

        _writer.WriteLine($"Calling: {name}");
        _writer.WriteLine($"Args: {args}");

        var watch = System.Diagnostics.Stopwatch.StartNew();
        
        // The intercepted method is executed here.
        invocation.Proceed(); 
        
        watch.Stop();
        var executionTime = watch.ElapsedMilliseconds;

        _writer.WriteLine($"Done: result was {invocation.ReturnValue}");
        _writer.WriteLine($"Execution Time: {executionTime} ms.");
        _writer.WriteLine();
    }
}

Step 2: Registering with Autofac

Next, we need to register our interceptor with Autofac in our composition root. To set the Logger to output to the console, we simply pass Console.Out as a parameter to its constructor:

var b = new ContainerBuilder();
b.Register(i => new Logger(Console.Out));
var container = b.Build();

Step 3: Enabling Interceptors

The third step is to enable interceptors on our types by calling the EnableInterfaceInterceptors() method during registration.

For this example, we’ll use a very simple Calculator class and an ICalculator interface as our intercepted type:

public interface ICalculator 
{
    int Add(int a, int b);
}

public class Calculator : ICalculator
{
    public int Add(int a, int b)
    {
        return a + b;
    }
}

Modify the composition root to register this type and enable interceptions:

var b = new ContainerBuilder();
b.Register(i => new Logger(Console.Out));
b.RegisterType<Calculator>().As<ICalculator>().EnableInterfaceInterceptors();
var container = b.Build();

Step 4: Associating Interceptors

Finally, associate the interceptors with your types. You can do this right in the registration chain by calling the InterceptedBy method:

b.RegisterType<Calculator>()
 .As<ICalculator>()
 .EnableInterfaceInterceptors()
 .InterceptedBy(typeof(Logger));

Once set up, the methods in the Calculator type will be intercepted by the Logger, outputting the following to the console:

macbook:aop cblanco$ dotnet run
Calling: aop.Domain.ICalculator.Add
Args: 5, 8
Done: result was 13
Execution Time: 0 ms.

Gotchas

It’s worth noting that you can also use attributes to associate interceptors with types. However, there are some caveats—for instance, you cannot use interception with private classes. You can find more details in the Autofac documentation.

Taking It Further: Implementing a Memory Cache

We’ve successfully wrapped our business logic with a logging interceptor without intermingling the code. But we can take this further by layering interceptors to stack functionality.

Let’s implement a simple memory cache. While not production-ready, it demonstrates how to combine interceptors to prevent executing an expensive method twice for the same arguments.

public class MemoryCaching : IInterceptor
{
    private Dictionary<string, object> _cache = new Dictionary<string, object>();

    public void Intercept(IInvocation invocation)
    {
        var name = $"{invocation.Method.DeclaringType}_{invocation.Method.Name}";
        var args = string.Join(", ", invocation.Arguments.Select(a => (a ?? "").ToString()));
        var cacheKey = $"{name}|{args}";

        if (!_cache.TryGetValue(cacheKey, out object returnValue))
        {
            invocation.Proceed();
            returnValue = invocation.ReturnValue;
            _cache.Add(cacheKey, returnValue);
        }
        else
        {
            invocation.ReturnValue = returnValue;
        }
    }
}

(Note: A robust implementation would need to handle the serialization of non-primitive arguments and create a proper string hash for the cache key, perhaps using Json.NET and xxHash.)

Layering Interceptors

Register both interceptors in your composition root and chain them onto the Calculator type:

var b = new ContainerBuilder();

b.Register(i => new Logger(Console.Out));
b.Register(i => new MemoryCaching());

b.RegisterType<Calculator>()
 .As<ICalculator>()
 .EnableInterfaceInterceptors()
 .InterceptedBy(typeof(Logger))
 .InterceptedBy(typeof(MemoryCaching));

var container = b.Build();

Now, let’s resolve the calculator and execute the Add method a few times:

var calc = container.Resolve<ICalculator>();

calc.Add(5, 8);
calc.Add(5, 8);
calc.Add(6, 8);
calc.Add(6, 8);
calc.Add(5, 8);

(To make the execution time difference obvious, I temporarily added a 1000ms thread sleep inside the Add method). As the terminal output shows, the first time a method is executed with specific parameters, it takes time. Subsequent calls with the same values are instant because the cache intercepts the call and returns the stored value:

macbook:aop cblanco$ dotnet run

Calling: aop.Domain.ICalculator.Add
Args: 5, 8
Done: result was 13
Execution Time: 1006 ms.

Calling: aop.Domain.ICalculator.Add
Args: 5, 8
Done: result was 13
Execution Time: 0 ms.

Calling: aop.Domain.ICalculator.Add
Args: 6, 8
Done: result was 14
Execution Time: 1004 ms.

Calling: aop.Domain.ICalculator.Add
Args: 6, 8
Done: result was 14
Execution Time: 0 ms.

Calling: aop.Domain.ICalculator.Add
Args: 5, 8
Done: result was 13
Execution Time: 0 ms.

Final Thoughts

We combined two interceptors to add rich functionality (logging and caching) to our app without modifying a single line of code inside the Calculator domain class. This makes our code easier to extend, maintain, and read.

Writing this post on a Mac using Visual Studio and .NET has been a great experience. I love that Microsoft is porting its technologies to other platforms, allowing us to work with the languages we love without being tied to a single OS.