Welcome to the new week!

Did you start your Event Sourcing journey but are unsure if it'll work on production? Or maybe you're there already and want to check how you can enhance it? I have something for you!

Domain-Driven Design Europe pre-conference workshop that I'll be giving this May. I plan to gather all my knowledge on this topic and synthesise it for you! I got it through my projects, working on Marten and EventStoreDB and helping others through my consultancy. It'll be an intensive but educational and fun experience (at least that's the goal!).

Check the details, and feel free to ask if you have any questions or concerns:

• Oskar Dudycz - Production-Grade Event Sourcing Workshop - Modelling, DevOps, Process

If you're still in the early phases, that's fine; I'm also doing closed workshops and consultancy. Check:

• training page on my website

• recommendations on my LinkedIn profile.

They should show how other folks liked it.

One of the reasons I included the DevOps and Process in the workshop's title is that I believe it’s essential to running software on production. Modelling and working on design are essential. We should not skip that, expecting design to emerge. Doing a healthy portion of design upfront is just cheaper, yet we should not forget to evaluate our assumptions and ideas. Building the right process and synergy between coding and operations is even more important. We also need to have the tools to do it.

The platform approach is pictured as the go-to solution for now. I have mixed feelings about it; too often, I see that core or ops teams rebranded to the platform team just weaponised with new tools. The platform approach can be really helpful in reducing the cognitive load, but it also doesn’t come with a price, and it’s not easy to achieve.

Charity Majors outlined the following pitfalls in her talk:

1. Running Too Much Software.

2. Writing Too Much Software.

3. Not Letting Product Teams Own Their Own Reliability.

4. Not Giving Engineers Enough Tooling to Understand Their Code as Well as Operate It

5. Being Confused About Who Your Customer Is.

6. Not Running Your Team Like a Product Team.

7. Not Paying Enough Attention to Cost and Spend as Part of Architecture and Planning

8. Not Constantly Looking for Ways to Deprecate, Delete, and Shed Responsibilities

Watch all in:

• Charity Majors - Perils, Pitfalls and Pratfalls of Platform Engineering

And I agree with all of that; I’d add to that Conway’s Law, which is inevitable. You cannot beat Conway’s Law like you cannot beat the gravity law. That’s also a topic of a great talk by Avraham Poupko:

• Avraham Poupko - You can’t fight Conway’s law

Ok, but getting back to operations. There are things that are just not easy; one of them is multi-region support. If you do it wrongly, your costs will skyrocket, your latency will be terrible and your brain will hurt.

Alex Strachan wrote a nice overview of multi-region architectures:

• Alex Strachan - Understanding Architectures for Multi-Region Data Residency

Interestingly, his first point is the same as Charity Majors in her talk: “Know Your Customer”. I can second that, without knowing customers, it is extremely hard to define the data governance practices as: isolation, consistency and replication needs.

One of the important (but dangerous) tools to make such systems work and available is caching. Our systems need to work without it, but thanks to the proper caching strategy, we can enhance user experience and decrease the solution costs (of course, that can go both ways). A nice case study on it was presented by RevenueCat. Read more:

• RevenueCat - Scaling smoothly: RevenueCat’s data-caching techniques for 1.2 billion daily API requests

Once we have that, we must also take care of the proper communication strategy to make the data flow smoothly. Check the case study by Lastminute.com on how they design the RabbitMQ messaging strategy:

• Lastminute.com - Evolution of a high-performance system: from synchronous to seamless scalability

And if you’re searching for communication standards, CloudEvents just reached CNCF graduation. That means that it reached the final maturity level criteria. CloudEvents is a specification for the metadata/header for events. It was started by Microsoft and mostly adopted in Azure for now.

I’d consider it in the cross-module communication. For inner module communication, this may be overkill. Still, it’s worth taking inspiration and checking if it matches your needs. Although it’s still surprising for me why they’re CloudEvents instead of CloudMessages, well… Read more:

• Cloud Native Computing Foundation - Announces the Graduation of CloudEvents

• Cloud Events Website

See also a nice material on pitfalls to avoid when building Event-Driven systems. It’s a nice set of advice around data governance:

• Kris Van Vlaenderen - 5 pitfalls to avoid when implementing an Event-Driven Architecture

Two weeks ago, I presented a great article by Ryan Shriver on his approach to Software Architecture Modernisation with DDD. Now, I’m even more than happy to say they took a step forward and published all of them as Miro board templates!

• SingleStone - New Miro Templates for Domain-Driven Discovery

I think that’s a must-have thing to check and play with; I’m planning to do it soon. That’s also a great spirit of sharing knowledge with the community. Kudos to them!

Btw. it’s a good time to remind the C4 template by IcePanel in case you missed it:

• IcePanel - C4 Model - Getting Started Workshop

Last but not least, Cloudflare shared its story on the last Thanksgiving Okta breach and its impact on Cloudflare. They wrote:

Even though we understand the operational impact of the incident to be extremely limited, we took this incident very seriously because a threat actor had used stolen credentials to get access to our Atlassian server and accessed some documentation and a limited amount of source code. Based on our collaboration with colleagues in the industry and government, we believe that this attack was performed by a nation state attacker with the goal of obtaining persistent and widespread access to Cloudflare’s global network.

Read the full coverage:

• Cloudflare - Thanksgiving 2023 security incident

It was yet another issue caused by Okta. Cloudflare was infected, but they claim that it didn’t target their customers, listing more details.

Below are the Indications of Compromise (IOCs) that we saw from this threat actor. We are publishing them so that other organizations, and especially those that may have been impacted by the Okta breach, can search their logs to confirm the same threat actor did not access their systems.

Funnily, we still didn’t get even comparable threat analysis from Okta besides the blank statements. It's a terrible sign for a company that aims to care about security.

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 - Production-Grade Event Sourcing Workshop - Modelling, DevOps, Process

• RevenueCat - Scaling smoothly: RevenueCat’s data-caching techniques for 1.2 billion daily API requests

• Lastminute.com - Evolution of a high-performance system: from synchronous to seamless scalability

• Alex Strachan - Understanding Architectures for Multi-Region Data Residency

• Alistair Cockburn - Hexagonal Architecture from its Inventor

• Ian Cooper - Adopting Polyglot Flow

• Cloud Native Computing Foundation - Announces the Graduation of CloudEvents

• SingleStone - New Miro Templates for Domain-Driven Discovery

• Jeff Atwood - When Understanding means Rewriting

• Kris Van Vlaenderen - 5 pitfalls to avoid when implementing an Event-Driven Architecture

DevOps

• Charity Majors - Perils, Pitfalls and Pratfalls of Platform Engineering

Databases

• Greg Wilson - SQL for Data Scientists in 100 Queries

Testing

• Microsoft - APIs testing using HTTP files and Rest Client

• Hillel Wayne - I have complicated feelings about TDD

AI

• LM Studio - Discover, download, and run local LLMs

• Rachel Coldicutt - Is it possible for general purpose AI to do no harm?

.NET

• Kyle Kukshtel - So You Wanna Package Some Native Libs Into A NuGet Package

• Nicholas Blumhardt - SerilogTracing

• Charles Chen - .NET Task Parallel Library vs System.Threading.Channels

• Egil Hansen - Testing .NET Web APIs from A to Z

Node.js

• Yoni Goldberg - The Node.js best practices list

Smalltalk

• Alec Sharp - Smalltalk By Example

TypeScript

• Christian Woerz - A Deep Dive into Advanced TypeScript: A Live Coding Expedition

Management

• Avraham Poupko - You can’t fight Conway’s law

• Jamie McDonald - Roadmaps are tools

• Sam-Nicolai Johnston - Improving Delivery Rate by Subtasking

Industry

• ArsTechnica - Google will no longer back up the Internet: Cached webpages are dead

Security

• Cloudflare - Thanksgiving 2023 security incident