Sneaky code bites back, I realised that again recently.

I realised I'd been writing terrible code when I couldn't explain it to myself.

The code worked. It was adding SQLite support to Pongo. But when I tried to describe how I was implementing multi-database support, I heard myself saying:

"First it checks if the Promise is cached, then it creates a proxy that defers to the real implementation which doesn't exist yet, but will be loaded dynamically when..."

Insane, I was going insane.

It's a pattern we all fall into.

We see repetition and think, "I can abstract this."

We see explicit configuration and think: "I can infer this". We see upfront costs and think: "I can defer this".

Sometimes we just don’t trust our colleagues, thinking that they’re too incompetent and we need to take precautionary steps.

Sometimes we're right. Most often we’re not.

Too often, we're optimising the wrong metric. I was optimising for fewer imports, not simpler code. I was hiding essential configuration, not accidental complexity.

A minimal API with complex implementation isn't simple—it's a lie. The complexity doesn't disappear. It moves from the visible surface to hidden internals, where it's harder to understand, debug, and modify.

I got too clever. We all do sometimes. The key is catching it before it escapes into production, where it becomes someone else's nightmare.

Now I'm removing this code, and that's fine.

Want to read details? Check the latest #ArchitectureWeekly https://www.architecture-weekly.com/p/sneaky-code-bites-back

And tell me about your sneakiness.

How hard did it bite you?

Do you want to learn more about cool #PostgreSQL features like partitioning, logical replication? Know also more about dos and dont's from my experience?

After receiving a ton of questions on last week's Particular Software webinar on #PostgreSQL Superpowers, I did a Q&A, discussing those topics (and more!)

Read it in the latest #ArchitectureWeekly: https://www.architecture-weekly.com/p/postgresql-partitioning-logical-replication

You'll also know what I answered for the question:

"What misuse of PostgreSQL (feature or in general) has turned out to be useful?"!

Feedback is welcome, and thanks again, @danielmarbach for the invitation!

“Just use #SQL”, they say.

“No need for ORMs”, they add.

And they may be right, but… But then accidental complexity piles in.

Just is enough for a simple or explicit context. Eventually, as our system grows, we’ll need to deal with complications. Popular tools might not be perfect; they may be too heavy, depending on design decisions, but as Gerald Weinberg said:

"Things are the way they are because they got that way"

You can live “just” with something. This can be a good starting point. Yet, we should always consider when deciding on DIY or “take off the shelve” solutions where we need to land and what our main problem is to solve.

Because if it appears that we’ll need more advanced features, then we’ll follow the path similar to the one that people building popular libraries/tools have taken.

It’s always worth thinking whether “just” will be enough for us. Usually, “just” is enough only for some time. And it is better not to overlook this to change our approach, as then we can deal with accidental complexity related to wrongly weighted “just”.

How does "wrongly weighted just" look like? Check in my latest #ArchitectureWeekly edition

https://www.architecture-weekly.com/p/just-use-sql-they-say-or-on-how-accidental

What are your "wrongly weighted just" horror stories?

Vertical Slices in software architecture are pictured right now as the best thing since sliced bread.

I won’t try to hide that, like it. I've written about CQRS and Vertical Slices over the years - how to slice the codebase effectively, shown examples, and explained why generic doesn't mean simple, yet…

I still get questions about Vertical Slices Architecture (VSA).

After a recent Discord discussion in the recent #ArchitectureWeekly, I want to share some additional thoughts on how I see Vertical Slices Architecture, how it relates to CQRS, what different slicing strategies are, and (of course) the tradeoffs.

But also why we love discussing it, and how Semantic Diffusion impacts that.

https://www.architecture-weekly.com/p/my-thoughts-on-vertical-slices-cqrs

What compilers have to do with event-driven pipelines? At first glance? Nothing! But after thinking about the new design in #Emmett, I changed my mind!

I wrote today on #ArchitectureWeekly on how building an Event-Driven pipeline led me to writing my own compiler. Oh well, small one, simple one, but still.

Read also about more surprising places besides programming languages when compiling happens, and helps your applications!

https://www.architecture-weekly.com/p/compilation-isnt-just-for-programming

Most of the time, we discuss strong consistency and eventual consistency.

Most systems prefer to have strong consistency. You perform the operation, wait till it’s finished and then proceed.

Take adding attachment to your business processes as an example. We could handle uploads synchronously. User selects file → browser uploads to server → server stores file → server creates database record → server returns success.

Simple, consistent, slow.

This creates problems:
1. Large files block the UI for minutes.
2. Network interruptions force complete restarts.
3. Servers become bottlenecks, streaming every byte through memory.
4. Multi-gigabyte files can crash servers.

Luckily, we learned that sometimes we have to live with an additional delay. Still, we should not stop that, as it’s a bit trickier than “a small delay”.

We usually assume that stuff will happen in a particular order, we just don’t know precisely when. And that’s actually something that’s called Causal Consistency. The difference between Eventual and Causal consistency is:

Eventual consistency - The system eventually reaches a consistent state. Order of operations doesn't matter. Create a link, then upload the file, or upload the file, then create the link - the result is the same. The system tolerates temporary inconsistency.

Causal consistency - Operations must respect cause and effect. You can't comment on a document before it exists. Effects follow causes.

File uploads fit eventual consistency perfectly. When attaching a blueprint to a construction task, two things happen: storing the file and linking it to the task. The order is irrelevant. What matters is that both are completed eventually.

With eventual consistency for file uploads, we can show files as "attached" immediately. The actual upload happens in the background. Of course, we won’t be able to download them until the upload is finished, but the system continues working during the brief inconsistency.

And that's also what I discussed today in details in the latest #ArchitectureWeekly.

I did a follow-up to last week's article about inverting dependency, this time expanding on how predictable ids can also help you to beat eventual consistency.

Read more: https://www.architecture-weekly.com/p/dealing-with-eventual-consistency

In distributed systems, we face a fundamental tension between module communication and module autonomy. Our modules need to exchange information and coordinate actions, yet we want each module to evolve independently without forcing changes across the entire system.

This tension becomes evident in event-driven architectures, where modules communicate through events and messages.

Consider a typical e-commerce platform. The payment module needs to process requests from orders, handle reimbursements, manage subscriptions, and potentially deal with dozens of other payment scenarios.

Each connection point between modules represents a potential coupling that can ripple through the system when requirements change.

The traditional approach involves modules directly referencing each other through event types, API endpoints, or shared data structures.

This creates a web of dependencies where adding a new module or changing an existing one requires coordinated updates across multiple teams.

What if we could enable modules to communicate without knowing about each other's existence?

What if a payment module could process requests from any source without being programmed to handle specific scenarios?

I've explored in the latest #ArchitectureWeekly how predictable identifiers, specifically Uniform Resource Names (URNs), provide an elegant solution to this challenge.

The key insight is that identity can carry meaning without creating coupling. URNs provide a standardised way to structure this identity, enabling infrastructure-level routing while maintaining module independence.

The payment module could process generic payment requests, inverting the dependency and publishing responses using the correlation ID for routing. It never needs to know whether a payment is for an order, reimbursement, or subscription.

Read more in https://www.architecture-weekly.com/p/predictable-identifiers-enabling

Are you using such an approach in your systems?

I've been facilitating the #EventStorming sessions for years now, and something keeps catching my attention.

While teams naturally focus on mapping out those orange event sticky notes (the backbone of any EventStorming session), they often underestimate the power of two critical elements: Hot Spots and Notes.

What I value most about Hot Spots and Notes isn't just how they improve workshops - it's how they change team culture around uncertainty.

In technical discussions, we often feel pressure to know everything immediately.

Hot Spots create permission to say, "I don't know yet" while still making progress. They transform uncertainties from conversation-killers into clearly defined next steps.

I've seen teams evolve from hiding what they don't know to actively hunting for uncertainties as valuable information. Questions become assets rather than liabilities.

If you're incorporating EventStorming into your toolkit, don't underestimate these powerful elements. They might not get as much attention as domain events, but in my experience, they often separate a productive modelling session from a frustrating stalemate.

Read more in the latest #ArchitectureWeekly: https://www.architecture-weekly.com/p/the-underestimated-power-of-hot-spots

Have you heard a surgeon say: "I won't sterilise my tools, as the patient won't let me"?

I haven't, but I have heard multiple times: "Business won't let us add unit tests."

As this grinds my gears, I decided to write my take on why we tell those lies to ourselves. I think that it's more about us avoiding accountability and dodging our duties than about mischievous business people.

Read more in the latest #ArchitectureWeekly: https://www.architecture-weekly.com/p/business-wont-let-me-and-other-lies

What's your take on that?