Welcome to the new week!

Psst, if you’re reading this email on Monday 26th, before 6 PM CET, then good news for you: you can still join a live webinar with Andrea Magnorsky on Introducing Bytesize Architecture Sessions!

I’m thrilled and curious to learn more about the idea of those small workshops that can bring big insights into our systems.

See more on the webinar page to join us live!

I released a new Emmett version! A bigger one! I added and released the package to build WebApis with Express.js. Now, you can implement fully-featured WebApi on top of event-sourced business logic. All of that with a minimum boilerplate and features like Problem Details for error handling, optimistic concurrency with ETags, etc. Read more in:

• Updated getting started guide,

• Release nodes.

Joins also our Discord Server and get the possibility to impact Emmett’s design and feature set!

Blogging is a great chance to get new insights, also for an author. I got some follow-up questions about my last week’s article on the Closing the Books pattern. I always learn something more by rethinking topics while preparing answers

Some people asked if really we should always keep our streams short in Event Sourcing. What about cases where we have long living but short streams, or it’s hard to find life cycles?

I also decided to write my answers and make them a blog article. Read more:

• Oskar Dudycz - Should you always keep streams short in Event Sourcing?

Speaking about rethinking, Jack Lindamood wrote up the lessons from building the infrastructure while leading a startup for 4 years.

• Jack Lindamood - (Almost) Every infrastructure decision I endorse or regret after 4 years running infrastructure at a startup

There are some obvious issues that we still do, like regretting “Multiple applications sharing a database”, but also those that are a bit contrarian, like regretting using DataDog or “Not adopting an identity platform early on”. In general, it’s a nice list of pragmatic, personal experiences to consider for our projects. You can agree or disagree with some points, but that’s fine and why we have such articles.

DoorDash, is an online food ordering company. They focused initially on restaurant deliveries and expanded to include groceries, retail, and pet supplies. This growth made their old setup for managing delivery preferences cumbersome and prone to errors. They built a new system to manage these settings better, aiming for a setup that could easily adjust to changes and new requirements.

DoorDash went for CockroachDB as a storage because it's built to scale out. Their data handling needs exploded as they expanded beyond just food to include groceries, retail, and pet supplies. They want to ensure that as the number and complexity of transactions grow, the database can keep pace by distributing the load across more resources. They wanted to scale out and keep the consistency and data integrity. For that, CockroachDB sounds like a nice match.

• DoorDash - Meeting DoorDash Growth with a Self-Service Logistics Configuration Platform

Yet, there’s no free lunch! (ba dum tsss), scaling out and keeping the consistency comes with the latency penalty.

ZITADEL Cloud (Identity infrastructure provider) ditched CockroachDB for PostgreSQL, taking a different route from DoorDash. They leaned towards PostgreSQL for its better fit with Google Cloud's Cloud SQL, aiming for more straightforward data management and cost savings. While DoorDash embraced CockroachDB for its distributed strength, ZITADEL found PostgreSQL's lower latency and reduced resource needs more aligned with their goals. Also, keep in mind their domain; they wanted to have more control over the data residence, etc. Read more:

• Zitadel - Why We Moved From CockroachDB to PostgreSQL

This shift underscores a key lesson: the best database choice depends on specific needs—speed, cost, and system simplicity for ZITADEL versus distributed resilience for DoorDash.

Check also a nice article from Vlad Mihlacea on how to tune your PostgreSQL performance:

• Vlad Mihalcea - PostgreSQL Performance Tuning Settings

Continuing with the decisions made or to be made. I have two interesting articles from Elizabeth Ayer. She coined a nice term: “enshittification”.

• Elizabeth Ayer - Enshittification as Overproduction in Software, Part 1: Seeing Overproduction

• Elizabeth Ayer - Enshittification as Overproduction in Software, Part 2: Overproduction in the product lifecycle

Elizabeth Ayer's take on "enshittification" boils down to a couple of practical moves: lean into Lean principles to cut the fluff and keep only what users actually need, and make sure your product doesn't gather unnecessary features as it grows. She suggests looking at what you're building through a lens of real user demand, not just adding stuff because you can. When your product hits that mature phase, it's all about refining and improving what's already there, rather than piling on new, possibly unwanted features. This approach keeps your software useful and prevents it from becoming overloaded and less valuable to your users.

Ayer also highlights the importance of having a clear direction for your product, especially as it matures. It's not just about what you're adding but also what you choose not to add. Keeping your team focused on enhancing the quality of existing features and being ready to ditch what doesn't work can help prevent your product from losing its appeal. In short, keep it simple, stay focused on what your users really need, and don't be afraid to cut features that don't add value. This way, your product stays relevant, efficient, and, most importantly, valuable to your users as it evolves.

“Enshittification” is definitely something that a new wave of Generative AI tooling should invest in.

The objectives and Key Results (OKR) framework, originally developed at Intel and popularized by Google, is gaining big popularity in our industry. I like the idea, but I have some concerns about its practical application. Seeing many lengthy resources and people making businesses implementing OKR in organisations makes me wonder if that’s really so practical. I have a hot-takish, but interesting rant on them:

• drmorr - OKRs are Bullshit

So, I don’t think that they’re bullshit, and I think that also an author, in his heart, doesn’t think that, but behind the angriness, there is some fair critique.

The push for 70% completion of objectives may inadvertently encourage unfinished work. At the same time, the quest for measurable key results can lead to the creation of metrics that divert focus from truly impactful outcomes. This rigidity, reminiscent of waterfall methodologies, seems at odds with the adaptability prized in agile development. The critique calls for a more nuanced, adaptable approach to goal-setting that prioritizes meaningful objectives over rigid adherence to measurable outcomes. It suggests that while OKRs aim to structure ambition and track progress, their implementation often misses the mark, potentially stifling innovation and flexibility in the dynamic tech landscape.

What’s your take on that?

From the different topics, it seems that performance geeks may have a new favourite language. The friendship with Rust may end for some, but now Mojo can be a best friend. At least if you’re building AI or big data transformations. Of course, if Mojo delivers and not be yet another buzzword, niche language. Check more:

• Modular - Mojo vs. Rust: is Mojo 🔥 faster than Rust 🦀 ?

Performance-wise, AWS released their own Node.js-compatible runtime: LLRT.

• LLRT - (Low Latency Runtime) is an experimental, lightweight JavaScript runtime designed to address the growing demand for fast and efficient Serverless applications

They claim that it’s “10x faster startup and up to 2x overall lower cost compared to other JavaScript runtimes running on AWS Lambda”. Of course, there are lies, big lies and benchmarks, but I believe that for AWS, that’s actually a good move. They know they setup and the typical usage of AWS Lambda. My guess is that most of Lambdas are running JS/TS-based functions, so building and maintaining their own tool is a nice idea. I’m not sure if that’ll eventually be a general-usage tool, but at least if you’re using AWS, then it can be a decent win.

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

• Oskar Dudycz - Should you always keep streams short in Event Sourcing?

• Jack Lindamood - (Almost) Every infrastructure decision I endorse or regret after 4 years running infrastructure at a startup

• DoorDash - Meeting DoorDash Growth with a Self-Service Logistics Configuration Platform

• Zitadel - Why We Moved From CockroachDB to PostgreSQL

• Randy Shoup - Minimum Viable Architecture

• Zhamak Dehghani - How to break a Monolith into Microservices

• Danica Fine - Brick-by-Brick: Exploring the Elements of Apache Kafka

• Barry M O'Reilly - Residuality and Representation: Toward a Coherent Philosophy of Software Architecture.

DevOps

• git-secrets - Prevents you from committing secrets and credentials into git repositories

• checkov - Prevent cloud misconfigurations and find vulnerabilities during build-time in infrastructure as code, container images and open source packages with Checkov by Bridgecrew

• Gitpod - Develop directly on a Kubernetes cluster using a CDE (Gitpod) and Telepresence

Databases

• Vlad Mihalcea - PostgreSQL Performance Tuning Settings

AI

• Open AI - Sora, Creating video from text

• Modular - Mojo vs. Rust: is Mojo 🔥 faster than Rust 🦀 ?

Azure

• Xavier Mignot - Terraform vs Bicep: the differences you should really know

Node.js

• Emmett - WebApi support

• LLRT - (Low Latency Runtime) is an experimental, lightweight JavaScript runtime designed to address the growing demand for fast and efficient Serverless applications

.NET

• Jeremy D. Miller - Dynamic Tenant Databases in Marten

• Tomasz Pęczek - Azure Functions Extensibility - Runtime Scaling

• Avalonia - Farewell to the .NET Foundation

• Andrew Lock - Using named pipes with ASP.NET Core and HttpClient

TypeScript

• Alexey Berezin - With or without enums in TypeScript

• TypeScript Worksheet - Get the results of your TS or JS code right in your vscode

• Twoslash - Markup for generating rich type information in your documentations ahead of time

Tools

• Draw.io - Interactive diagrams with custom links and actions

Product Design

• Elizabeth Ayer - Enshittification as Overproduction in Software, Part 1: Seeing Overproduction

• Elizabeth Ayer - Enshittification as Overproduction in Software, Part 2: Overproduction in the product lifecycle

Management

• Chris Matts, Olav Maassen - "Real Options" Underlie Agile Practices

• drmorr - OKRs are Bullshit

Security

• Microsoft Threat Intelligence - Staying ahead of threat actors in the age of AI