Welcome to the new week!

For many years, I’ve been trying to convince others that Event Sourcing is not so scary and is quite useful. I truly believe in that, yet…

I see a chasm between its initial simplicity and its use in production. In our past webinar, Alexey Zimarev said that we need Event Sourcing frameworks. After thinking about it, I agree with that take. We’re not yet in the adoption phase to not need a framework or library. I have started packing my Node.js samples into the package in the last few months, resulting in…

Emmett: a framework that will take your applications back to the future. The idea behind Emmett was to make it easier to create business-focused applications and cut unnecessary code without using magic. The combination of using events and their business focus, the expressiveness of TypeScript and the lightness of Node.js is supposed to help with that.

Take an open mind, cover it with a Constructive Critic hat if necessary, and see and discuss live what you think about it! We’ll built live a simple, but real-world API and discuss what’s next for Emmett!

The webinar will happen on Wednesday, June 26th, at 6 PM CEST (UTC+2) and last 1-1.5h depending on the number of discussions.

Become a paid subscriber and join us live!

I got positive feedback about my recent DevOps stuff and Docker Compose (like load balancing with Nginx), so here we go with another one! This time, I showed how to set up pgAdmin with a Docker database automatically.

I also explained how to improve the local development experience by eliminating annoying papercuts like having to always log in or set up a connection inside pgAdmin.

That setup is quite often missing. Read more in:

• Oskar Dudycz - How to automatically setup pgAdmin with a Docker database

Architecture is about making decisions, those important ones. Making decisions can be hard; I wrote about it in Why are we afraid of our decisions? It can be painful, especially if we don’t have other people to discuss and challenge our thoughts. Quite often, we bounce back and forth, going through all the stadiums: happiness about revelation, denial, frustration, and (hopefully) acceptance.

Pierre Pureur and Kurt Bittner touched on this in their latest article:

• Pierre Pureur, Kurt Bittner - Architectural Trade-Offs: the Art of Minimizing Unhappiness

They went through the rational process of making those decisions and trying to make it less frustrating. They suggested the following things to improve your decision process:

1. Get better at generating reasonable alternatives.

2. Don’t expect technology to make decisions for you. (OD: Cheers LLM!)

3. Get good at forming hypotheses and running lowcost experiments that yield results quickly.

4. Be willing to admit you were wrong and pivot as quickly as possible.

5. Understand the cost of rolling back decisions that later prove unworkable.

Read more; the article is good for thoughts; also check past webinar with Laïla Bougriâ on debugging our thinking:

Architecture Weekly

Webinar #18 - Laïla Bougriâ: Debug your thinking

Did you feel that you need to debug your mind? Did your (or your colleague's) biases impact your decision-making? How to improve it? How do you reason about the reasoning? Laïla Bougriâ shared with us practical thoughts and the results of their research backed by the history of her projects. She gave us the talk she gave as the…

Listen now

3 months ago · 7 likes · Oskar Dudycz

Some people say architecture and system design is the art of balancing coupling. I’m not a big fan of such a statement, as coupling is a vague term. It can mean anything, depending on who’s saying that.

To me, coupling is an attribute of our system, and low coupling shouldn’t be the end goal. Why? If we managed to somehow get zero coupling, then it’d mean that we don’t have system design but systems design. Literally, it means that those pieces are not having any relationship with each other. Wikipedia states that:

A system is a group of interacting or interrelated elements that act according to a set of rules to form a unified whole.

If we don’t have interaction, then we don’t have coupling, which also means we don’t have a system. So, no-coupling is, to me, more like a political statement or a talk-to-the-hand type of argument to stop discussion.

We should focus more on real/business capabilities rather than discussing coupling.

A great article on that comes from Gregor Hohpe when he analysed the many faces of coupling:

• Gregor Hohpe - The Many Facets of Coupling

Another interesting take on this topic is Connascence metric:

Connascence is a metric, and like all metrics is an imperfect measure. However, connascence takes a more holistic approach, where each instance of connascence in a codebase must be considered on three separate axes:

1. Strength. Stronger connascences are harder to discover, or harder to refactor.

2. Degree. An entity that is connascent with thousands of other entities is likely to be a larger issue than one that is connascent with only a few.

3. Locality. Connascent elements that are close together in a codebase are better than ones that are far apart.

The three properties of Strength, Degree, and Locality give the programmer all the tools they need in order to make informed decisions about when they will permit certain types of coupling, and when the code ought to be refactored.

Check also more in the good talk by Jim Weirich:

• 📺 Jim Weirich - Connascence Examined

Switching to another topic, but not that far, as we’ll get back to the outcome of a not-great tradeoff analysis. Three weeks ago, I wrote about the Snowflake at centre of world’s largest data breach. We learned more about that, or didn’t we? Let’s have a look.

To recap, Hackers stole terabytes of data from Ticketmaster, Santander and 165 other Snowflake cloud database engine customers. They got to those accounts because Snowflake exposed public databases without the need for a private connection or MFA. The tradeoff was to enable quick onboarding, ignoring common security practices.

One of the most common security investigators, Mandiant (now part of Google), released a report confirming that hackers stole credentials from third-party contractors. However, they didn’t give more clues on how they did it. Still, the report show some additional details on what came later:

• Mandiant - UNC5537 Targets Snowflake Customer Instances for Data Theft and Extortion

Wired, in their coverage, claiming that they spoke with one of the hackers, wrote that the contracting company was EPAM.

• Wired - Hackers Detail How They Allegedly Stole Ticketmaster Data From Snowflake

This is a big outsourcing company that’s an official partner of Snowflake. EPAM denied those claims:

• EPAM - Response to Hacker Misinformation Regarding Data Breach

Sounds like a blame game has started. Nevertheless, of whose credential was stolen, the issue is always that if you’re using a foot gun solution, then you’ll eventually shoot yourself. And that’s what Snowflake did, exposing databases publicly without MFA. I’ll keep you posted on the next news, as I feel that this story is just starting to unfold.

Not to end up with a bad taste in the mouth, let’s finish with good coverages of observability and nice tools to enhance that:

• Johan Olsson - OpenTelemetry Part 3 - Observability

• Clickhouse - Building an Observability Solution with ClickHouse - Part 2 - Traces

• qryn - a fast, thin, all-in-one polyglot observability stack built on top of ClickHouse

• Nikolay Sivko - You're overpaying for OpenTelemetry's verbosity by at least 30%

I’m personally plan to spend some time checking Clickhouse for the telemetry data correlation with business processes.

Check also other links!

Cheers

Oskar

p.s. I invite you to join the paid version of Architecture Weekly. It already contains the exclusive Discord channel for subscribers (and my GitHub sponsors), monthly webinars, etc. It is a vibrant space for knowledge sharing. Don’t wait to be a part of it!

p.s.2. Ukraine is still under brutal Russian invasion. A lot of Ukrainian people are hurt, without shelter and need help. You can help in various ways, for instance, directly helping refugees, spreading awareness, and putting pressure on your local government or companies. You can also support Ukraine by donating, e.g. to the Ukraine humanitarian organisation, Ambulances for Ukraine or Red Cross.

Architecture

• Gregor Hohpe - The Many Facets of Coupling

• 📺 Jim Weirich - Connascence Examined

• Pierre Pureur, Kurt Bittner - Architectural Trade-Offs: the Art of Minimizing Unhappiness

• 📺 James Eastham - So You Want to Build An Event Driven System?

DevOps

• Oskar Dudycz - How to automatically setup pgAdmin with a Docker database

• Jesse Chen - Improving CI/CD with a Focus on Developer Velocity

• Johan Olsson - OpenTelemetry Part 3 - Observability

• Clickhouse - Building an Observability Solution with ClickHouse - Part 2 - Traces

• qryn - a fast, thin, all-in-one polyglot observability stack built on top of ClickHouse

• Nikolay Sivko - You're overpaying for OpenTelemetry's verbosity by at least 30%

Databases

• Manticore Search - Easy to use open source fast database for search

Frontend

• Dominik Dorfmeister - React 19 and Suspense - A Drama in 3 Acts

• Nadia Makarevich - I tried React Compiler today, and guess what... 😉

• Carson Gross - htmx sucks

AI

• Felix GV - Lessons Learned from Building LinkedIn’s AI Data Platform

Azure

• Tore Nestenius - DefaultAzureCredentials Under the Hood

Go

• Miłosz Smółka - Live website updates with Go, SSE, and htmx

Java

• Venkat Subramniam, Josh Long - What's Looming in Spring?

.NET

• YoshiMaker - Serializers in IoT: Json.NET and System.Text.Json are Both Terrible!

• 📺 Dennis Dietrich - Introduction to unsafe C#: Calling native code and crashing in entirely new ways

• João Antunes - Transactional outbox pattern meets distributed tracing and OpenTelemetry

• Freakout - Just a general outbox thing

WebAssembly

• 📺 Katie Bell - Don't Trust Anything! Real-world Uses For WebAssembly

Security

• Wired - Hackers Detail How They Allegedly Stole Ticketmaster Data From Snowflake

• EPAM - Response to Hacker Misinformation Regarding Data Breach

• Mandiant - UNC5537 Targets Snowflake Customer Instances for Data Theft and Extortion

Trivia

• Dan Luu - How (some) good corporate engineering blogs are written