When people talk about error culture, there’s a common story that pops up:

You drop a cup in the kitchen as a kid.

Your parent yells: “Why can’t you pay attention just once?”

It’s a familiar moment for many—and also a classic fallacy.

Here’s the problem: the reaction assumes attention is binary. Either you’re paying 100% attention and nothing ever breaks, or you’re somewhere between 0–99%, and eventually something will break.

So if you want to “win,” you have to pay perfect attention all the time. That might sound responsible—but it’s incredibly inefficient.

Let’s talk opportunity cost.

In the example with a child, the cost of constantly paying attention isn’t obvious. Some might argue, “What’s the problem? The kid has plenty of time and energy. But we—the adults—have limited time and budget.”

Fair enough. But let’s take a different example where the cost is more tangible:

I’m self-employed and work full-time. My partner does too. We try to stay healthy by cooking meals from scratch, one or two times a day.

That’s 10 meals a week. At roughly 30 minutes per meal, that’s 5 hours. Based on my hourly rate, those hours have a real monetary cost—well into the three figures.

Meanwhile, our kitchen gear? Mostly Ikea-level basics. For example, the Pokal glass from Ikea costs €0.59.

I break something maybe once every one to two months.

You don’t need a PhD in math to realize: spending extra time and energy being ultra-careful with €0.59 items simply doesn’t make economic sense. The opportunity cost of working slowly far outweighs the occasional broken glass.

So for me, the only logical conclusion: I’m working too slowly in the kitchen.

This realization only clicked for me after reading about the concept of an error budget in the book Site Reliability Engineering: How Google Runs Production Systems.

The idea is simple:

• Define an acceptable rate of failure—an error budget.

• If you’re within budget: go faster, take reasonable risks.

• If you’re over budget: slow down, invest in stability.

An error budget gives your team something critical: a foundation for discussion and a guiding star for the messy reality of day-to-day operations.

It helps avoid the trap of striving for perfection when it’s not economically justified. It replaces shame with pragmatism.

So let me ask you:

What’s your error budget in the kitchen? How many glasses per month is it okay to break?

I’ve been experimenting with a new approach lately. It’s elegant, modern, and ambitious. But it only really works… if everything goes perfectly.

You’ve probably seen similar patterns with the latest “real” continuous delivery setups:

• You work in pairs and perform continuous code reviews.

• You commit directly to the main branch.

• Your changes are tested—but only your own microservice. God forbid that you test it together with other services.

• The changes are deployed directly to production. Of course, everything is covered by perfect and all-encompassing integration and end-to-end tests.

• If something fails, the changes are automatically reversed.

• Naturally, all your database migrations are designed to be fully backwards-compatible.

Sounds like a great plan—if all the planets are aligned.

But let’s be honest: how often are the planets aligned?

My impression is that many of these approaches share a common characteristic: the relationship between how well you implement the process and the benefit you get isn’t continuous—or even linear. It’s more like a discontinuous jump function. You’re either doing it perfectly or you’re in trouble.

I’ve seen this dynamic before, often involving coaches or consultants:

• You pay a hefty price.

• You allocate significant capacity across your team.

• You’re proud of reaching 90% adoption of the new model.

• Then something breaks. Everything falls apart.

• And the coach says: “Well, it’s not working because you missed this minor detail.”

They often come armed with a collection of wise-sounding quotes:

“I can show you the door. I can even open it for you. But you have to go through it yourself.”

“Sometimes it must get worse before it gets better.”

“Maybe the downtime of your production system isn’t a technical problem. Maybe it’s a symptom of your mindset."

Sure, some systems in life are truly binary. You’re either pregnant or you’re not. There’s no such thing as being a little bit pregnant.

But most organizational changes should yield continuous output based on continuous input. You put in 20% effort, you get a return. You put in 50%, and you get even more return. That’s how most real-world systems—and the Pareto Principle—work.

So if a new approach requires complete adherence before it delivers any results, it’s worth pausing.

Because then, you’re no longer optimizing. You’re gambling.

And if it really is a binary system, then the risk-reward ratio must be evaluated carefully. Otherwise, you might find yourself in a situation where you’ve invested everything and get nothing—because one minor clause wasn’t fulfilled.

What’s your take on approaches that only work when done 100% right?

I recently stumbled across Redpanda, and I have to say—it looks like a really promising alternative to Apache Kafka.

On paper, Redpanda offers some compelling benefits:

• Kafka compatible

• Simpler to run: Just a single C++ binary. No JVM. No ZooKeeper. No extra services.

• AI-first and built for global scale

The pitch seems tailored for massive-scale applications—but what caught my attention is how much it might benefit local development and smaller projects too.

Kafka has long been the standard, but let’s be honest: running Kafka locally is a pain. You need multiple services, ZooKeeper, a bunch of tuning, and still end up wrestling with configs just to get things working.

Redpanda promises to flip that experience.

With Docker Compose, you can spin up a single Redpanda broker. Suddenly, the barrier to using an event streaming platform locally becomes much lower. For prototyping or small team environments, this kind of simplicity could be a game-changer.

Now, let’s talk pricing.

Redpanda Serverless in AWS’s eu-central-1 region starts at $171.74/month (about €147.60), offering a write throughput of 0.1 MB/s. By comparison, a managed Kafka cluster in Frankfurt clocks in at around $148.80 (€127.31).

Question to the “Event Driven Bros” here: Is Redpanda an alternative for smaller projects?

Recently, I had what might be the worst travel experience of my life. A combination of the worst airport and the worst airline.

First, we stood in line at the gate—standard fare. Then we were herded down a narrow staircase into a holding room. After that, they led us into a fenced-off corridor, standing outside without any shelter, in the cold, without jackets, like cattle on their final walk to the slaughterhouse.

Why? All so that the plane wouldn’t spend a single unnecessary second on the ground.

This kind of "efficiency" isn't unique to airlines. You see it everywhere in B2C—where most of us spend our lives as consumers, especially in our early years.

It's always about maximizing throughput. The actual lead time—how long it takes from intent to outcome—is often ignored or forgotten altogether.

We’re conditioned for this from a young age.

Remember being told off for starting the dishwasher when 𝘫𝘶𝘴𝘵 𝘰𝘯𝘦 𝘮𝘰𝘳𝘦 𝘱𝘭𝘢𝘵𝘦 could’ve fit? But what if there 𝘸𝘢𝘴𝘯’𝘵 another dirty plate at the time? So you wait. After the next meal, you add the plate—and now the kitchen is full of dirty dishes. Great throughput, terrible lead time.

And this mindset creeps into our business decisions.

Take the Vercel and Next.js community, for example. You often see posts like:

"I’ve built this awesome SaaS app, but nobody’s using it yet. When someone 𝘥𝘰𝘦𝘴 visit, it takes 4 seconds to load. What can I do?"

Here’s an idea: put it in a container and keep your cache warm.

"But then I’m paying for a container that nobody uses! That’s wasteful!"

That right there is the flaw in thinking.

Sure, your app isn't used most of the time—but when someone 𝘥𝘰𝘦𝘴 show up, you have seconds to make a good impression. Those cold-start delays can kill a lead.

Let’s do the math: If you need 10 website visits to get 1 click to your web app, and 10 users in your app to get 1 sign-up, that’s 100 ad clicks per registration. At €5 per click in a B2B market, that’s €500 for a single registration.

And you're worried about €10/month for a warm container?

You're not going to get that kind of cost-efficiency on AWS when you factor in hidden costs like load balancers. But platforms like DigitalOcean's App Platform make this kind of setup easily achievable.


So here’s my question to you:
When you run the dishwasher even though it 𝘤𝘰𝘶𝘭𝘥 have fit one more plate—are you being wasteful, or are you optimizing for lead time?

I recently watched some videos by Golo Roden from the native web GmbH on his YouTube channel, and they sparked some thoughts around CQRS and Event Sourcing.

Let’s take a practical example: implementing a marketplace where users can search for bicycles.

In such a system, you usually have two very different concerns—writing data (like creating or updating listings) and reading data (like searching for bikes based on filters). That’s where the CQRS (Command Query Responsibility Segregation) pattern comes into play.

The idea is simple but powerful: split your application into two parts. The write side handles commands—data changes—and writes to a relational database like PostgreSQL. PostgreSQL offers strong consistency, referential integrity, and powerful features like constraints and transactions. It’s the ideal choice for managing critical business data with precision.

On the read side, you want to provide a smooth and fast experience when users are searching for bikes. This is where ElasticSearch enters the picture.

The data is denormalized and synced from PostgreSQL into ElasticSearch. Denormalized means it's tailored for fast access: no complex joins, no foreign key lookups, just flat and queryable data.

The biggest advantage? Your queries become much simpler. You get automatic indexing, which is a huge time saver. Need full-text search across multiple fields? Done. Want to aggregate results by location, brand, or price range? ElasticSearch handles that effortlessly. These are things that would require non-trivial SQL and manual index tuning in PostgreSQL.

So with CQRS and ElasticSearch, you decouple complex domain logic from high-performance querying. You get strong guarantees on the write side and fast, flexible queries on the read side.

And now you: Have you used CQRS with ElasticSearch in your projects?

If you're developing serverless applications in the cloud, you're likely familiar with this scenario: You create a pull request (PR) with your changes to introduce a new feature. After all the static code analysis and unit tests pass successfully, the PR gets reviewed and merged.

But then—what’s that?

After merging the changes, the CI pipeline deploys them… and everything breaks!

What’s going on?

It comes down to distinguishing between build-time and run-time errors. In the old days of on-premise infrastructure, you could be reasonably confident that you'd catch run-time errors while testing locally.

A typical setup might include a Java backend and a PostgreSQL database. If calling an endpoint that runs a database query worked locally, it was unlikely to fail at runtime in production.

But in a typical serverless environment, things work differently:

Let’s say you have an API Gateway that exposes a REST interface and invokes a TypeScript Lambda function, which stores data in a DynamoDB table.

While developing locally, you might:

• Mock the AWS-specific dependencies

• Use emulators like LocalStack

• Abstract the cloud calls and replace them with local alternatives (e.g., writing to disk instead of uploading to S3)

But this is exactly the problem!

What are you really testing? You're only verifying that your application works with your mocked, emulated, or abstracted dependencies.

The solution? Ephemeral Environments.
For every PR, provision all the required cloud resources and deploy the PR’s code into that environment. If needed, you can copy production data or seed services like S3 and DynamoDB with test data.

This setup enables you to run integration and end-to-end tests before merging changes into the main branch.

Some might suggest another approach: run the Lambda handler locally while using real AWS resources like DynamoDB. But this introduces risk—using the same resources as your production environment is dangerous.

And that’s the key:
You need dedicated, isolated resources for each PR.

Which brings us back to ephemeral environments.

Now it's your turn: Are you using ephemeral environments?

As software developers, we often have an intuitive understanding of infrastructure costs and the expenses associated with certain backend operations.

Right?

That may have been true in the pre-public cloud era and is still partially true for hyperscalers in the public cloud, such as AWS.

However, the problem is that many cloud resources are not billed “per item” (e.g., “per DynamoDB table”) but rather per API operation. And here’s where things become unintuitive: some API operations are not as obvious as they seem.

Let me give you an example:

There was a DynamoDB table with a lot of data, used for testing purposes, and it needed to be emptied regularly.

Unlike relational databases such as PostgreSQL, DynamoDB does not support a simple “DELETE * FROM table” operation. Instead, you must delete items in batches—up to 25 items at a time. This means looping through the table and deleting items in batches until it’s empty.

Sounds simple and cheap, right?

Not quite. If you perform a large number of write, read, or delete operations in a short burst, DynamoDB may throw throttling exceptions. But shouldn’t it scale effortlessly and almost infinitely, like the name “DynamoDB” suggests?

Yes, it does—but gradually, over time. While it scales to handle consistent high usage, it has limitations when dealing with sudden burst loads.

This can be mitigated by purchasing provisioned capacity to prepare the table for heavy usage. But this approach is inefficient—why pay for provisioned capacity all the time if you only empty the table once a week?

And here’s the next gotcha: in DynamoDB, you pay for each write and read operation. So, is deleting items free?

Unfortunately, it’s not. A delete operation counts as a write operation. Deleting a lot of items can quickly become expensive.

This highlights why relying on your intuition from on-premises systems can be risky when estimating costs in the public cloud.

Pro tip: If you run into this specific issue, there’s a loophole—deleting an entire DynamoDB table is free. So, if you want to delete all items from a table without incurring write operation costs, just delete the table and recreate it with the same settings.

And now you: What’s the most unintuitive cloud cost you’ve run into?

On a rainy Friday, your product owner asks you to do a complex database migration. After reading the requirements and acceptance criteria of the Jira ticket, you think: “F**k! This cannot be done easily!”

The problem is that the change is so complex, it cannot be done gracefully. You have to stop the backend, make a dump of the database, delete the old database, create a new database, and then run a complex migration script. Finally, you have to make sure that the backend works with the new database.

If anything breaks during the process, you have to roll everything back manually. Hopefully, that’s even possible.

What if the backend doesn’t work with the new database? Then you have to make the hard choice: spend all the effort and roll it back, or do ad-hoc changes to the backend in the middle of the night while you’re tired.

Even if this process works, you’ll be extremely exhausted — and this will have a negative impact on your private life during your free weekend days.

And if it doesn’t work? You’re screwed! Maybe you can summon a few colleagues and spend the rest of the weekend fixing it. Maybe you can’t fix it — and on Monday, you’ll be called by some angry customers. If your company is big, you’ll even read about it in the news.

The root cause of this is hubris: you think you’re a 10X developer who can do things with an all-at-once approach. Your genius, you believe, allows you to take a shortcut and avoid the rough road of a blue-green deployment with zero downtime.

What would be the better approach?

Provision a new database in parallel with the existing one. Write to both databases simultaneously. Use the old schema for the old one and the new schema for the new one. Run a migration script that reads historical data from the old database, converts it to the new schema, and writes it to the new database. After a grace period, start reading from both databases and compare the results. If, after another grace period, the results are always the same, you can start using only the new database and archive the old one.

So what’s the difference between the approaches?

The first is an all-at-once approach that relies on your genius as a 10X developer to take a leap of faith into the unknown. The second is a professional software development approach that does things incrementally, safely, and predictably.

How do I know this? I’ve taken the leap of faith countless times. And in 99% of cases, I regretted it.

Do you think confidence in tech is often mistaken for competence — especially when taking all-or-nothing risks?

Is it ever justifiable to go with an all-at-once approach in software — or is it always a sign of hubris?

A backend contains business logic and interfaces to the outside world. Oftentimes, the advice is to extract as many non-business-logic responsibilities from the backend application as possible and move them to standalone components in the infrastructure.

An example is CORS headers: every response from the backend to a client should contain the Access-Control-Allow-Origin header to inform the client (browser) whether the frontend is allowed to call the backend.

This can be handled in the backend. Most frameworks — like Hono — provide pre-built middleware for this purpose. Just call app.use(cors()) in your main function, and everything will work.

Another approach is to let the load balancer (e.g., Nginx) set the headers. In this case, the backend application is not even aware of the concept of CORS.

If you want to compare the two approaches, you have to consider two cases:

1. Deployed system (development and production environment in the cloud)

2. Local development setup

Let’s start with the deployed system:

When a browser makes a request — for example, a POST request to the backend — and the backend is not on the exact same URL and port as the frontend, it will first send a preflighted OPTIONS request to the backend. The backend must respond — among other things — with the CORS headers like Access-Control-Allow-Origin. If everything is correct, the browser will then send the actual POST request.

Load balancers are capable of caching OPTIONS requests, so there will be far fewer requests to the backend.

Additionally, if there is a separate infrastructure team from the application team, setting the correct CORS headers could be enforced company-wide, and the application team doesn’t have to worry about it.

Now let’s look at the local development setup:

If you let the load balancer handle CORS, it won’t work when running your frontend and backend locally. Your browser will complain that there are no CORS headers. Thus, you have to set up a local load balancer like Nginx. In this setup, your frontend will call the load balancer, which will then forward the request to your backend.

This introduces more complexity.

How do you want to run the load balancer? As a system service in your Linux OS? As a Docker container? In a Docker Compose setup?

Who will configure and maintain the load balancer configuration? How do you keep it in sync across all developer machines?

If you use orchestrator frameworks like Vercel’s Turborepo for Node.js, it's more complicated to integrate the lifecycle of non-Node.js systems such as Nginx into the task dependency graph.

In production environments, it's generally preferable to handle CORS at the infrastructure level (e.g., via nginx or an API gateway). This centralizes configuration, allows for caching of preflight requests (if configured), and enforces organization-wide security policies without burdening the application team.

However, in local development, requiring a load balancer adds unnecessary complexity. Developers must manage extra tooling and keep configurations synchronized across environments. Instead, handling CORS within the backend application using middleware (like app.use(cors()) in Hono) simplifies the development setup and improves the developer experience (DX).

Suggested approach:

Use a hybrid strategy:

• In development, implement CORS in the backend for simplicity.

• In production, shift CORS to infrastructure for scalability, consistency, and better separation of concerns.

Do you think the infrastructure or the backend application should handle CORS?