Sponsor: Do you build complex software systems? See how NServiceBus makes it easier to design, build, and manage software systems that use message queues to achieve loose coupling. Get started for free.

Welcome to the new week!

People fear the wrong state in the event streams while not being afraid of traditional storage. And here's the deal: both may be broken the same way. The difference is that we may not even notice that it's broken in the traditional storage.

We'll see that in Event Sourcing because we have tools for that. Event streams, if modelled correctly, can give us explicit details on the current state, why it is like that, and how we got here.

In my latest article, I expanded using the hotel housekeeping schedule adjustments as an axis for dealing with the change in Event Sourcing. Change is always hard; I understand that. Not knowing about the bad case can be more blissful than knowing the hard truth.

Still, if we don't want to ignore the facts and create proactive systems, then having a clear view is a big benefit that shouldn't be seen as a challenge. Read more:

• Oskar Dudycz - Oops I did it again, or how to update past data in Event Sourcing

I'm delighted that Derek Comartin is doing the hard work for me so often. In the last few days, I was asked by 3 different people about the Listen to yourself "pattern". It's great that I could link Derek's video and just say ditto:

• Derek Comartin - Alternative to the Outbox Pattern? Not so fast

Listen to Yourself is one of those "patterns" that came right from the tooling limitations to work around them and get so popular that they started to be called a pattern. From my perspective, it's mostly anti-pattern as the real usage is limited. It introduces the consistency difficulties that could be handled using the right solutions, like the Outbox pattern or not treating the queue as a database.

I think that it's mostly valid for scenarios where you need to accept incoming commands and then process them later. Such a scenario could be useful for peeks in traffic like BlackFriday order processing, as queues (e.g. SQS, SNS) can usually be autoscaled horizontally easier than databases.

One small difference from the video is that I believe that ES subscriptions are not necessarily implementations of Listen To Yourself; I think that they're more Outbox built into event stores.

How do you deal with consistency and handling business workflows properly, then? Yves Reyhnout provided a great answer for that:

• Yves Reynhout - The Workflow Pattern

You rarely see blog articles that show breakthroughs and trigger such in the readers. I was searching independently for the essence of the modelling and explaining how to model asynchronous/distributed processes and straightforwardly implement them. You can see that in:

Architecture Weekly

Webinar #3 - Implementing Distributed Processes

Watch now (100 mins) | Distributed processes with an event-driven approach embrace the impossibility of the two-phase commit in distributed transactions. Instead of trying to make a big transaction across modules and databases, it does a sequence of microtransactions. Each operation is handled by the module that’s the source of truth and can make autonomous decisions. The distributed process is triggered by the event registered and published in the system, e.g. shopping cart confirmed…

Read more

a year ago · 2 likes · Oskar Dudycz

Yet, what Yves provided is a condensed and actionable explanation. Rarely are patterns prescriptive. I’d compare the importance and the impact similar to Jérémie Chassaing's Decider.

It’s a must-read for anyone interested in Event-Driven Architecture.

One of the conclusions from the previously mentioned articles is that aligning your architecture with the business problem is critical. We see emergent approaches like team topologies and platform engineering. I’m not so gullible to hope that all companies will understand the impact of Conway’s Law and the need to reduce cognitive load. Still, I hope those approaches will be expanded enough to impact our industry more.

We’re not Business and IT anymore; now, IT is a Business.

Ryan Shriver did an intriguing case study on how you can align your cloud architecture with business:

• Ryan Shriver - Domain-Driven Cloud: Aligning Your Cloud Architecture to Your Business Model

Of course, I’m not a huge fan of the buzzwords like Domain-Driven Cloud. They sound cheesy, but you probably need a catchy term to promote the approach.

Still, the article is good. It explains and presents a good framework for how to start your architecture design. It promotes the approach by starting with a logical split based on the business domain, then breaking it down into bounded contexts (modules), thinking about the expected workloads and aligning that with cloud technologies.

This article also aligns well with articles I linked in past editions:

• Gregor Hohpe - Cloud Automation à la DDD: From stringly typed to affordances

• Uber - Introducing Domain-Oriented Microservice Architecture

It’s important to remember that the cleanness of the approach is not an end goal. The end goal is to deliver software that fulfils business requirements and does that correctly. We should not make rotten compromises around performance just because we want clean code or architecture. Those terms are blank and can be interpreted in numerous ways.

Our solutions need to be user-friendly but also machine-friendly.

Read more on how to build proper solutions, focusing on the approach's performance and correctness.

• Alex Russell - A Management Maturity Model for Performance

• Seth Eliot - Any Day Can Be Prime Day: How Amazon.com Search Uses Chaos Engineering to Handle Over 84K Requests Per Second

One of the things that we’re missing in our industry is accountability. We’re too focused on measuring the metrics instead of focusing on the outcome and being accountable for it. Aaron Stannard took the try to describe that challenge:

• Aaron Stannard - Internal vs. External Accountabilities

He broke down accountability into three groups:

1. Accountable to customers or potentially other external stakeholders, like investors. (…)

2. Accountable to team - this is the middle management-tier responsibility. (…)

3. Accountable for individual performance - this is individual contributor responsibility. (…)

These accountabilities compound on top of each other - high-level executives are still accountable to the team AND still accountable for their own performance.

I think that we should realise that we’re all accountable to someone, and delivering a proper solution is a joint effort of all parts. Of course, building the right process that enables good from people is essential, but we should also not forget to make them accountable.

I wrote about that in On the importance of setting boundaries in team management.

Read also an interesting interview with Ron DeVera, ex-Twitter (or ex-X…) Staff Engineer. He shares his lessons learned on how to influence the outcome, dealing with difficult coworkers and managing up:

• Jordan Cutler - Influence: Lessons from a Staff Engineer and ex-Twitter 8-year Tech Lead

Check also other links!
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

• Oskar Dudycz - Oops I did it again, or how to update past data in Event Sourcing

• Yves Reynhout - The Workflow Pattern

• Ryan Shriver - Domain-Driven Cloud: Aligning Your Cloud Architecture to Your Business Model

• Derek Comartin - Alternative to the Outbox Pattern? Not so fast

• Mark Schwartz - Everyone is Busy: Who Has Time to Transform?

• Alex Russell - A Management Maturity Model for Performance

• Rob Eisenberg - Yo Ho Ho and a Bottle of RUM

DevOps

• Seth Eliot - Any Day Can Be Prime Day: How Amazon.com Search Uses Chaos Engineering to Handle Over 84K Requests Per Second

• GitLab - 2023 Global DevSecOps Report

• ChartMuseum - an open-source, easy to deploy, Helm Chart Repository server

JavaScript

• Matteo Collina - My thoughts on Bun and other Adventures

AI

• HuggingFace - Red-Teaming Large Language Models

Java

• Inside Java - The Arrival of Java 21!

• Per Minborg - Java Records are "Trusted" and Consequently Faster

.NET

• Jeremy D. Miller - Wolverine Expands its Multi-Tenancy Story to HTTP

• Maarten Balliauw - Discriminated Unions in C#

• Michal Strehovsky - Reverse engineering natively-compiled .NET apps

• Andrew Lock - Introducing the Identity API endpoints

Rust

• JetBrains - Introducing RustRover – A Standalone Rust IDE by JetBrains

Coding Life

• Arslan Ahmad - Mastering the System Design Interview: A Complete Guide

• Atlassian - Merging vs. Rebasing

Management

• Aaron Stannard - Internal vs. External Accountabilities

• Jordan Cutler - Influence: Lessons from a Staff Engineer and ex-Twitter 8-year Tech Lead

Industry

• The Street - Salesforce CEO takes another bold stand on remote work

• IEEE Spectrum - The Top Programming Languages 2023, Python and SQL are on top, but old languages shouldn’t be forgotten

• ArsTechnica - Linux gives up on 6-year LTS kernels, says they’re too much work

• phoronix - The Maintainer Of The NVIDIA Open-Source "Nouveau" Linux Kernel Driver Resigns

Tools

• Free for Developers - This is a list of software (SaaS, PaaS, IaaS, etc.) and other offerings with free developer tiers

Security

• The Record - Microsoft accidentally exposed 38 terabytes of data from employee workstations

• ZDNet- Microsoft's CISO: Why we're trying to banish passwords forever

• GitHub - Passkeys are generally available

• The Web SSO Standard OpenID Connect: In-Depth Formal Security Analysis and Security Guidelines