Architecture Weekly #94 - 26th September 2022

Oskar Dudycz

Sep 26

▷ Listen

SAVE

Welcome to the new week!

There are a few hills I could die on in tech discussions. Both are related to confusing explanations of the simple concepts: CQRS and Event Sourcing.

Recently I read yet another terrible take about them both. This time from AWS:

Modernize legacy databases using event sourcing and CQRS with AWS DMS

I also had a discussion on Twitter about the complexity attached to CQRS.

All of that made me create such a meme.

Unfortunately, most of the material shows a skewed perspective about CQRS, not the original definition. CQRS is about separating behaviours in your architecture to writes and reads. It's about focusing on the business operations and ensuring that "writes" (so business logic) are separated from the read operations. That's not related to messaging, event sourcing, eventual consistency, etc. It's about making clear operation intentions and segregating them. I wrote longer about the common myths in my article:

CQRS facts and myths explained

Today at 4 PM CEST, we’ll have the next webinar for paid subscribers community. We’ll discuss:

Why would someone consider using CQRS instead of CRUD?
If there’s the truth in myths like: CQRS needs multiple databases, it is about messaging tools and brings eventual consistency.
Is CQRS more complex, and is work going slower than in CRUD?
What are the benefits and challenges?

Feel invited!

We work in an industry that’s full of passionate people. Doing what you like and getting paid for it is a privilege and a curse. We’re vulnerable to workaholism and burnout. I hear many stories from my colleagues about not wanting to quit their current job because they care too much about the team, rare tech stack, or money, even though they’re constantly tired. Many times I wasn’t great at caring about my mental safety. You can do better. Leaving a toxic job is not quitting. It’s self-defence. Check more in my latest article:

On the importance of setting boundaries in team management

Thinking for yourself and questioning authorities is one of the most important aspects of proper design. Too often, we’re so focused on our first thought or habits that we’re not even checking if there’s a better alternative. Routine kills innovation and also can drive us to dangerous cliches. On my teams, I always demanded explanations of the thrown-away alternative solutions. If there were none, that usually meant that team didn’t do the homework. Check more about that in:

If you’d like to see how lousy reasoning and lack of challenging discussion may end up, read:

Varun Cheedalla - Microsoft Kin—The Billion Dollar Smartphone Disaster

Nowadays, if we’re not thinking upfront, our pockets may be hit immediately. In one of my past projects, we were thinking about using DynamoDB. It provides superb latency and matched our data design, yet we didn’t use it in the end. It appeared that using DocumentDB would be good enough for our case and much cheaper. Read more about such dilemmas in:

Forrest Brazeal - The cloud billing risk that scares me most as a developer

We’re saying that nothing is lost on the Internet. It may appear soon that this statement is not precise anymore. Web Archive is having issues, check more in:

Slate - Could the Internet Archive Go Out Like Napster?

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 Red Cross, the Ukraine humanitarian organisation. You may also consider joining Tech for Ukraine initiative.