dvdcst.dev

The read replica your code doesn't know about

dvdcst — Sun, 26 Jul 2026 00:00:00 GMT

Every backend I have worked on eventually hits the same problem. There is one endpoint, usually a listing or a report, that reads a lot and returns a lot, and it slowly becomes the reason the database has a bad day. Someone opens the catalog page, the query goes through a few million rows, and every write happening at that moment waits in line behind it.

The textbook answer is boring and correct: send those reads to a replica. You probably already have one, or you can create one in a few minutes on any managed database. The primary handles writes, the replica handles the heavy reads.

The part the textbook skips is the annoying one: how do you route a specific request to the replica without passing a connection object through every method that might touch the database?

I got this wrong a few times before I got it boring. This is the boring version, in .NET. It is smaller than the title suggests: it routes a whole request to one server, not each query, and that limitation is what keeps it clean.

The naive fix

The first instinct is to pass the connection down. You add a second DbContext, a ReplicaCatalogDbContext, and inject it into the one controller that needs it.

That works for exactly one endpoint. Then the report calls a service, the service calls another service, and now you are passing a "which database" flag through five layers that had no business knowing a database exists. Every new read path becomes a decision. Every refactor drags the flag along.

I have written that version. It looks fine in the pull request and it is annoying six months later.

What I wanted was this: the service layer stays exactly as it is, and somewhere else, out of the way, something decides which connection this request uses. One place. One line per endpoint.

Context, not a parameter

"Which database does this request use" is not a parameter, it is context. It belongs to the request, not to any function inside it. So instead of passing it down, you put it somewhere the whole request can read, and you read it back when you open the connection.

The simpler version of this uses a static AsyncLocal<bool>. I prefer a scoped service: it already has a per request lifetime, it is easier to test, and it does not leak request state into work that outlives the request.

public enum DatabaseTarget
{
    Primary,
    Replica
}

public sealed class RequestDbTarget
{
    public DatabaseTarget Target { get; set; } = DatabaseTarget.Primary;
}

That is the whole state, and it defaults to the primary so forgetting to decide is the safe option. Register it as scoped:

builder.Services.AddScoped<RequestDbTarget>();

A note on the name. My first version called it ReadOnly, which was a lie: nothing here makes anything read only, and the compiler will happily send a SaveChangesAsync to a replica that rejects it at runtime. DatabaseTarget.Replica says what it actually does, which is pick a server.

Flipping the target without touching the handler

I want to mark an endpoint the same way I mark any other cross-cutting concern: with an attribute. Nothing inside the action changes, I just tag it.

[AttributeUsage(AttributeTargets.Method | AttributeTargets.Class)]
public sealed class UseReplicaAttribute : Attribute { }

The attribute does nothing on its own. A small middleware, placed right after routing so the endpoint is already resolved, is what reads it and sets the target:

app.UseRouting();

app.Use(async (context, next) =>
{
    var useReplica = context.GetEndpoint()?
        .Metadata.GetMetadata<UseReplicaAttribute>() is not null;

    if (useReplica)
    {
        context.RequestServices
            .GetRequiredService<RequestDbTarget>()
            .Target = DatabaseTarget.Replica;
    }

    await next();
});

There is a requirement hiding here: this middleware has to run before anything resolves the DbContext. Usually that is free, since the context is created when the controller asks for it and the controller runs after routing. But if some earlier middleware resolves CatalogDbContext for its own reasons, the connection string is already chosen and your target arrives too late. The order is part of the design, not a detail.

The DbContext picks a side

Two connection strings in configuration, nothing exotic:

{
  "ConnectionStrings": {
    "Primary": "Server=primary;Database=Shop;...",
    "Replica": "Server=replica;Database=Shop;..."
  }
}

And the registration reads the target when it builds the options:

builder.Services.AddDbContext<CatalogDbContext>((sp, options) =>
{
    var target = sp.GetRequiredService<RequestDbTarget>().Target;
    var config = sp.GetRequiredService<IConfiguration>();

    var connectionString = target == DatabaseTarget.Replica
        ? config.GetConnectionString("Replica")
        : config.GetConnectionString("Primary");

    options.UseSqlServer(connectionString);
});

That is it. No branching inside a controller, no second context injected by hand, no flag travelling through the service layer. The decision lives in two places that already existed for infrastructure reasons.

One note: this assumes the default EF Core lifetime, one context per request, connection chosen when the context is built. If you use AddDbContextPool or an IDbContextFactory the timing changes, because a pooled or factory built context does not necessarily read your scoped target when you expect it to.

What the endpoint looks like now

The heavy listing that used to bully the primary:

[UseReplica]
[HttpGet("products")]
public async Task<IEnumerable<ProductDto>> ListProducts(
    [FromQuery] ProductFilter filter)
{
    return await _catalog.Search(filter);
}

One attribute. Now picture the calls underneath:

ProductsController
   -> CatalogService
      -> InventoryService
         -> PriceService

None of those services knows a replica exists. CatalogService.Search runs the same query it always ran, against a connection it never chose, and that connection now points at the replica. The write endpoints next to it keep hitting the primary, because they are not tagged.

When a new report shows up next quarter, pointing it at the replica is a one line diff. Nobody has to open a service to do it.

It routes a request, not an operation

This is where the pattern stops being magic. The target is set once, for the whole request, before any database work happens. Every query in that request goes to the same server. Usually that is what you want. Sometimes it is not.

Picture an endpoint that writes and then reads its own write:

public async Task<IActionResult> Save(ProductInput input)
{
    await _catalog.Update(input);

    var refreshed = await _catalog.ListProducts();
    return Ok(refreshed);
}

You cannot tag that one with [UseReplica]. The update goes to the primary, and the read right after it also has to go to the primary, because the replica may not have caught up and would return the version from before you saved. That is not a read only request. It is a write request that happens to read afterwards, and both halves belong on the primary.

So be honest about what this buys you. It has no answer for "write to the primary, then run a heavy report on the replica, in the same request". When a request genuinely needs both, this is the wrong tool. Per operation routing exists, you pick a connection at each query, it just costs a lot more machinery and pushes the concern back into the code you were trying to keep clean. Most apps do not need it.

Replicas lag

A replica is not a faster copy of the truth. It lags, and it lags in ways that matter.

The classic trap is read after write across two requests. A user updates their shipping address, the browser immediately refetches the profile, and if that read went to the replica it may come back with the old address. The user thinks the save failed. It did not, you just asked the wrong server.

The rule I settled on is simple: the replica is for reads that tolerate slightly stale data. Catalogs, dashboards, reports, search. Anything a user just wrote and expects to see back stays on the primary.

One replica, used on purpose, beats twelve you cannot explain (via @devhumour.ai)

A replica can also fall behind under load and it can fail over. None of this is a reason to avoid replicas, it is a reason to be deliberate about which endpoints you point at one. Which is exactly why I like that the decision is one visible word above a method instead of a default buried in a service.

Closing thoughts

This pattern hides in the two places that were already infrastructure. The middleware was going to exist. The DbContext registration was going to exist. The service layer, the part that is actually mine to get right, never learns any of this is happening.

That is the same idea I keep writing about from different angles: spend your cleverness once, in a corner, and be boring everywhere else. A read replica is about as boring as infrastructure gets, and switching an endpoint onto it now costs one word above a method. The 10PM version of me, debugging a slow query during an incident, will be glad the routing is in one obvious place and that its one limitation is written down instead of discovered.

Boring Technology Wins

dvdcst — Fri, 29 May 2026 00:00:00 GMT

Every few months some new tech trends:

A brand new database that will finally replace Postgres
A language that will finally kill PHP
A paradigm that makes everything you shipped last year look naive

The industry never runs out of "one more standard

Four years ago I would read the announcement, get excited, and start rewriting something that was working perfectly fine.

These days I read the announcement, think "cool", and go back to my Postgres, node and .NET. For a while I assumed this was the moment developers stop optimizing for novelty and start optimizing for reliability.

It is not that. Boring is a feature, and as usual it took a few late-afternoon incidents to understand why.

Boring does not mean outdated

Boring technology is technology whose failure modes you already know. Postgres is boring not because it is old, but because when it breaks, it breaks in ways thousands of people have already documented on every imaginable place. Its behavior under load is known. Its sharp edges are mapped. The set of things that can genuinely surprise you is small, and most of the surprises that remain are one search away from someone else's postmortem.

A shiny new database might be better on paper. But every property of it is an unknown to you, and unknowns are not free. You pay for them later, usually at the worst possible time, usually with interest.

The cost of new is paid later, by a tired version of you

In an earlier post I mentioned that the 10PM version of me is always more tired and less patient than the 9AM one. Boring technology is mostly a gift to that person.

When you reach for the exotic tool, you are making a bet that you, or whoever is on call, will still understand it in eighteen months.

Some times you are just cooked

That the maintainer will still be around. That the three GitHub issues describing your exact problem will not be the only three that ever existed (and they never was solved). Every one of those bets is fine in isolation. The trouble is that they compound, and the bill always arrives during an incident, never during a calm Tuesday.

Someone once framed this as a budget of innovation tokens: you get a small number, and every novel choice spends one. The mistake I made for years was spending them on infrastructure, the part of the system that is supposed to be invisible, instead of saving them for the part that was actually mine to solve.

Hype optimizes for the demo, not for Tuesday

A lot of technology looks incredible in a fancy conference talk. Five minutes, a clean dataset, a problem shaped exactly to fit the tool. That is the demo.

Then you take it home and run it against real data, real concurrency, real users doing things no one designed for, and a deploy pipeline that has to keep working at 3AM. That is Tuesday. Most hype is tuned for the demo. Boring tech has already survived a few thousand Tuesdays, which is the only review that has ever mattered to me.

This is also why I distrust benchmarks more than I distrust my own taste now. A benchmark is a demo with a chart. The question I actually care about is not "how fast is it when everything goes right", it is "how badly does it hurt when something goes wrong", and nobody puts that on a landing page.

Spend your novelty where it actually matters

None of this is an argument for never trying anything. It is an argument for choosing one place to be interesting and being aggressively dull everywhere else.

When I built a daily movie guessing game a while back, the only genuinely novel part was the data generation concept: generating a full year of daily prompts with an LLM ahead of time and matching player guesses with some string-distance math. Everything around it was deliberately boring. A static frontend. No backend. No auth. Hosted on a reliable and safe infrastructure I already understood. The boring scaffolding is exactly what let me pour all of my attention into the one part that was worth the risk.

That is the whole trick. Identify the single hard problem that is the reason your project exists, spend your novelty there, and let the rest of the stack be as unremarkable as possible. A system where everything is exciting is a system where everything can fail in a way you have never seen.

Closing thoughts

Choosing boring technology is not a sign that you have stopped caring or stopped learning. It is usually the opposite. It means you have been burned enough times to know that the goal was never to look clever in a code review.

The goal is to still understand the system when you are tired, to fail in ways you can predict, and to spend your limited capacity for risk on the one problem that deserves it. Boring is what is left after you remove the parts that were only there to impress someone.

Most of the time, that is the whole system.

Knowing When to Let a Project Die

dvdcst — Wed, 27 May 2026 00:00:00 GMT

Every developer has a graveyard. Mine has a CHIP-8 emulator from a couple of years ago, half a college RPG written in C, a Gatsby portfolio (and a Next.js one, and a... you got it), some automation scripts that solved problems I no longer have, and a notebook full of side project ideas I will never start.

For a long time I treated this as a personal flaw. Lack of discipline, lack of focus, lack of something. Then I noticed that the developers I respect have graveyards too, sometimes bigger than mine. And the ones with the smallest graveyards were not the most productive ones, they were the most boring ones.

So the real question is not how to stop abandoning projects. It is knowing when abandoning is the correct move, and when it is just the easy one.

After enough years doing this, I noticed my abandonments fall into four buckets.

1. The project that taught you and stopped

This is the classic one. You start a CHIP-8 emulator because reading about how old systems worked feels exciting. The first week is amazing, opcodes mapped, display rendering, the test ROM finally showing something. Then you hit the part that is just... typing. The drawing logic, the input handling, the edge cases of the BCD instruction.

The dopamine drops. The IDE stays closed.

I have a folder for this kind of project. F0ReST, the text RPG from college that ended its life with a single bear fight and an ASCII title screen. The CHIP-8 I keep promising myself I will go back to. A Lex/YACC compiler I wrote for the same class and never extended.

The honest truth: most of these should be abandoned. Their purpose was learning, and the learning happened in week one. Finishing them would teach me nothing new, just punish me for getting excited in the first place.

The trap is feeling guilty about it. Guilt makes you start the same kind of project next month, because deep down you think this time you will be different. You will not. Accept the pattern, archive the repo, move on.

2. The project that life outgrew

This one hurts more, because the project was good and you were enjoying it.

A while ago I jumped into Omarchy, an Arch based distro built around a tiling window manager. The first week was a series of small battles: Wi-Fi through a TUI whose keybindings I had to look up on GitHub, a Brazilian keyboard layout that broke the installer, workspaces in a world where minimizing a window is not a concept. I had a good time anyway. The system was fast, the workflow was interesting, my desktop looked like a screenshot from r/unixporn.

I am not on Omarchy anymore. I am on Fedora.

Nothing about Omarchy got worse. I got busier. Personal life, hobbies that do not involve a screen, friends, family. At some point I noticed I was spending Saturday afternoons tweaking waybar instead of doing the things I had actually been wanting to do. The operating system became the project, and the project was competing with my life.

Fedora boots, runs my stack, and asks for nothing back. That is exactly what I needed.

This kind of abandonment is different because the project was not the problem. The problem was the position it occupied in my week. Sometimes the move is not to finish or quit, it is to demote.

3. The project built to die

A while back I built a small daily browser game: three emojis and a couple of cryptic clues, and you had to guess the movie. It was supposed to die, and it did.

I knew up front that it would be online for one year. Twelve months of daily challenges, then dark. That decision changed everything about how I built it: no auth, no backend, no scale considerations, no roadmap. A static frontend, some clever string distance for typos, and a year of prompts generated with an LLM.

It ran for the full year and then I pulled the plug. The numbers were exactly what I expected on one side and slightly unsettling on the other: a small but steady stream of players from week one to week 52, and a roughly equal stream of bots and would-be hackers prodding the infrastructure the entire time. Two flat lines on the same chart, one of users, one of attackers, oddly similar in shape. A small reminder that anything you put on the public internet is interesting to someone, even if the someone is a script.

This is the most underrated way to "abandon" something. You decide at the start that the project has an expiration date, and that frees you to make it exactly as small as it needs to be. No premature scaling. No "what if it goes viral". No five year vision document.

It also makes the eventual shutdown emotionally trivial. You are not abandoning anything, you are collecting on a debt the project owed you from day one.

4. The project that knows when it is done

The other side of the coin.

Right now I am building a small endless runner. Nothing ambitious, a single mechanic, minimal art, maybe a leaderboard if I feel generous. What makes it different from most of my graveyard projects is not a deadline, it is the definition. Before I wrote a line of code I knew exactly what "done" looked like for v1. Whether it eventually ships to a store, sits on itch.io, or just lives on my hard drive is a separate decision and frankly a smaller one.

That distinction matters more than I used to think. A deadline is about when you stop. A closed scope is about what counts as stopping. Most of my graveyard had neither.

Writing down what "done" means before the first commit sounds boring, and it is. It is also the cheapest insurance I have found against scope creep, against losing interest halfway through, against the project quietly mutating into something I no longer want to finish. The plan can still change, but at least there is one to change.

How I decide now

When I feel the urge to walk away from something, I run a short list before I close the tab:

Did I get what I came for? If the project was learning, did I learn the thing? If yes, abandoning is fine. The repo is just a receipt.
Is the next 20% going to teach me anything? If the rest of the work is mechanical execution of stuff I already know, the project is done in my head. The code just has not caught up.
Am I quitting because it is hard, or because it is not mine anymore? Hard is a reason to push through. Not mine anymore, when my life has shifted and the project belongs to a previous version of me, is a reason to let it go.
Did I promise anyone, including myself, that this would ship? If yes, finish it. Even a small public commitment matters more than most people admit.

Most of the time the answer is "yes, abandon it", and the guilt is what makes me hesitate, not the project itself.

Closing thoughts

The graveyard is not the problem. The problem is treating every project like it has to live forever, and then feeling like a failure when something does not.

Some projects are lessons. Some are built to die. Some are demoted because life got bigger. And every once in a while, one is built knowing exactly what done looks like.

All four are fine. The trick is knowing which one you are holding.

My Mental Model for Writing Simpler Backend Systems

dvdcst — Thu, 05 Mar 2026 00:00:00 GMT

After enough APIs built, legacy systems refactored, and late night production incidents, something started to become obvious: backend engineering is not about frameworks. It is about reducing chaos.

Which caos you ask?

I know, this sounds like a goofy tech coach quote, but is the reality. The client doesn't care about our event based systems, CQRS and AWS, they want a report when they click the blue button, a cheaper infra and the most specific possible business rules on production.

That creeping disorder even has a name: code entropy the natural tendency of systems to drift toward complexity and disorder as they grow, requirements shift, and teams change.

Reducing the said chaos is not easy, and to aid myself i have this is the mental model I try to follow when I write code. It's not perfect. It's not finished. It's what I aim for.

1. My job is to reduce chaos

Systems grow, rules change, people leave. If the system becomes harder to reason about over time, I failed. Backend exists to create boundaries, clear ones. And that's it. Computers are designed to be predictable machines, and our code should be designed with this on mind.

2. Business rules are sacred

Frameworks change, cloud providers change, databases change. Business rules stay. I try to keep domain logic isolated, avoid coupling rules to transport (HTTP, queues), and test rules independently from infrastructure. Infrastructure serves the domain, never the opposite.

This sounds obvious until you're three sprints deep into a codebase where the business logic lives inside a controller.

3. Clarity beats cleverness

If I need to explain it twice, it's too complex. I prefer explicit names, small functions, predictable flow, and less magic. Code should feel boring and stable. The kind of code you open six months later and immediately understand. That's the goal, like a old school COBOL system.

4. Design for today, evolve when it hurts

I don't optimize for imaginary scale. I solve the current problem well, then I observe. Premature complexity is just ego disguised as foresight. We've all done it, it's never worth it.

5. Failure is expected

Networks fail, dependencies fail, people make mistakes. Good backend systems fail predictably, log with context, avoid corrupting state, and prefer idempotent operations when possible. Resilience is intentional. You don't stumble into it.

6. Decisions must be reversible when possible

Not every decision needs a committee. If it's reversible, I decide. If it's expensive, I document and chat with my Lead. Progress beats paralysis, we do async work. And most decisions are more reversible than they feel in the moment.

7. Production is the final judge

Opinions don't matter more than logs, metrics, and real user behavior. If it's not observable, it's not reliable. No matter how elegant the architecture looks on a whiteboard.

8. Simplicity is responsibility

The goal is not to impress. The goal is to make the system understandable for the next engineer, including future me. And the 10PM future me is always more tired and less patient than present 9AM me.

Closing thoughts

This is not rocket science. Backend is not about being brilliant. It's about building systems that survive change, entropy, and people. Do good work. That's the standard.

Local Backup with rsync and bash

dvdcst — Tue, 07 Oct 2025 00:00:00 GMT

Introduction: 15 gigabytes is not enough

Not having all the projects and assignments I did in college neatly organized in a single directory is one of my biggest regrets as someone who spends most of his life in front of a computer. Whether it was because of the infinite Google Drive storage my university provided, or the countless flash drives, emails, and random files I sent and received through every possible communication channel during those five years.

As with all good things, I knew the infinite drive wouldn’t last forever, and as soon as I graduated, I transferred everything to my personal Google Drive.

Big mistake

In one second, 99% of my free tier storage was gone, filled with messy, duplicated, and poorly formatted files, with the bonus that not everything had actually been transferred. The solution: throw everything onto my computer and pray the hard drive doesn’t melt.

For about two years, it actually didn’t melt, and the data stayed there, but the paranoia of losing everything started to take up a few bytes of my mental hard drive.

Until last week...

Hardware recycling

Eventually, a 256 GB SSD from an old PC landed on my desk. It was the perfect excuse to finally bring some order to the chaos and, at the same time, stop depending on Google Drive.

With a cheap external case, I turned that loose SSD into an external drive, and with a bit of bash, decided to write my own simple, straightforward local backup script. And to make it even better, I decided not only to back up my college files but also my code repositories and my Obsidian vault, my semi-second brain.

Rsync and paranoia

My idea was to have two mirrors:

From PC to SSD, the main backup. From SSD to PC, a local copy, because redundancy is never too much.

This way, even if the SSD dies, I still have a version on my computer, and vice versa.

Without reinventing the wheel, I chose Rsync, the command-line utility for syncing and transferring files between locations.

The script

The script below mounts the SSD, if it isn’t already, synchronizes the configured directories, and generates logs for each run. Simple, direct, and efficient.

#!/bin/bash

# === Configurations ===
SSD_MOUNT="/run/media/SSD" # the directory where I mount the SSD
SSD_UUID="062C43D82C43C303" # obtained via lsblk -f
PC_BASE="/home/me" # my home folder
BACKUP_DIR="$PC_BASE/Backup"
LOGFILE="$PC_BASE/sync-backup.log"

# === Functions ===
log() {
    echo "[$(date '+%Y-%m-%d %H:%M:%S')] $1" | tee -a "$LOGFILE"
}

check_or_mount() {
    if mountpoint -q "$SSD_MOUNT"; then
        log "SSD already mounted at $SSD_MOUNT"
    else
        log "SSD not mounted, attempting to mount..."
        sudo mount UUID="$SSD_UUID" "$SSD_MOUNT"
        if mountpoint -q "$SSD_MOUNT"; then
            log "SSD mounted successfully."
        else
            log "Failed to mount SSD at $SSD_MOUNT, aborting."
            exit 1
        fi
    fi
}

# === Execution ===
log "=== Starting sync ==="
check_or_mount

log "PC → SSD (Repositories)"
rsync -avh --delete --exclude 'node_modules' "$PC_BASE/Work/Repositories/" "$SSD_MOUNT/Repositories/" | tee -a "$LOGFILE"

log "PC → SSD (Obsidian)"
rsync -avh --delete "$PC_BASE/Work/Obsidian/" "$SSD_MOUNT/Obsidian/" | tee -a "$LOGFILE"

log "SSD → PC (Local backup)"
rsync -avh --delete "$SSD_MOUNT/" "$BACKUP_DIR/" | tee -a "$LOGFILE"

log "=== Sync completed ==="

Running the script is simple, just grant execute permission.

chmod +x local-sync.sh # or whatever name you gave it
./local-sync.sh

The small details

Fixed UUID, avoids headaches when the SSD changes its mount path. Logs, each execution is recorded, so you know what got updated.

--exclude 'node_modules', saves time and space. --delete, keeps mirrors truly in sync, but use with caution.

To run automatically, you can add this script to cron and let the system handle the rest.

Conclusion: goodbye infinite drive

With a small SSD and a 40-line script, I built a local backup routine, fast and 100% under my control. No subscriptions, no slow uploads, and no dependency on any big tech goodwill.

Sometimes progress is just deciding to take care of your own chaos, but I still miss that infinite drive, maybe I’ll enroll in a new college somewhere again...