Architecture Weekly #159 - 25th December 2023
Welcome to the new week!
It’s the last release this year! I hope you’ll find some time in those last days of the year to take a breath and relax. I hope I’ll have it too! And well, reading for me is also a form of relaxation, so if it’s the same for you, let’s give you something to read and watch!
Last week, we did a longer Read’n’Discuss session about the origins of the Saga pattern. It took us 2 hours and 20 minutes to review Hector Garcia-Molina’s and Kenneth Salem’s article introducing this concept. It’s actually good reading and easy to follow up. It took some time because we wanted to be sure that we got all the thoughts behind it and understood its impact. It’s a paper from 1987 and has aged well; its impact is undeniable.
See the whole recording:
It’s not that I only check old stuff; I like to try new things, and that’s what I did with the latest product from Microsoft, .NET Aspire. And the result wasn’t promising. I concluded not to use it for now. Read more on why:
I was going back and forth on whether to write it, but I think people should see different opinions to make a proper judgement. That’s why I decided to balance mostly the hyped comments I saw.
My main issue is that finding the main goal is not easy for me. For basic projects, the setup is overly complicated. For bigger projects, the stack is too opinionated and differs from the commonly used practices (e.g. it introduces its own control plane). Read more how it works internally in:
After posting this article, I had a good discussion with David Fowler and Reuben Bond under my LinkedIn post. I appreciate that they took their time to discuss my concerns and provide their thoughts on it. Read more here to see their perspective.
Yeah, going down the rabbit hole can be both intriguing and challenging. That’s also why I respect people taking their time to do a deep dive.
You won’t find a lot of deeper dives into databases than what Jepsen is doing. They’re continuously verifying the promises from databases and other tools around consistency, availability, etc. They’re not taking things for granted but have actual skills and tools to verify them. That’s what they did with MySQL:
You can find some surprises to the promised guarantees:
“MySQL is a popular relational database. We revisit Kleppmann’s 2014 Hermitage and confirm that MySQL’s Repeatable Read still allows G2-item, G-single, and lost update. Using our transaction consistency checker Elle, we show that MySQL Repeatable Read also violates internal consistency. Furthermore, it violates Monotonic Atomic View: transactions can observe some of another transaction’s effects, then later fail to observe other effects of that same transaction. We demonstrate violations of ANSI SQL’s requirements for Repeatable Read. We believe MySQL Repeatable Read is somewhat stronger than Read Committed. As a lagniappe, we show that AWS RDS MySQL clusters routinely violate Serializability. This work was performed independently without compensation, and conducted in accordance with the Jepsen ethics policy.”
Of course, it doesn’t mean you shouldn’t use it; most of that stuff can be caught only on the high load, but it’s good to know what you’re signing for.
Read also a great, extended article on PostgreSQL transaction isolation by Gwen Shapira:
Continuing with the databases but a much shorter and concise article. Check a general guide from Yan Cui on how to migrate the database without downtime:
Of course, the advice is sound, but doing that can be more tricky than it can appear through skimming.
I think that the most important part of making it easier is not making breaking changes. I wrote about it longer in Let's take care of ourselves! Thoughts on compatibility, but TLDR, you can perform any change in a way that won’t break other people's work.
Pete Hodgson explained how to do it for contracts by examples (with nice visualisations). It’s not rocket science, but it requires a consistent approach and common understanding.
Can you do the same with your domain model? Yes, you can. Julien Topçu, Josian Chevalier provided their idea of performing iterative evolution of your design:
He made intriguing note about us trying to be rational and trying to find always a pattern that’d be best to solve things:
“(…) It's the rational model. That's the attractive nuisance. The rational model was what we were chasing for decades in the software world, to our detriment. (…)
But it's not how you build things of any complexity, (…) In engineering processes, people are part of the system. And one of the nice things about the Agile crowd that you and I both know so well, [is that] from those old days, there was a lot of explicit acknowledgement [that] people are parts or components of these systems, both the system of designing and [the system of] building the software. And, in most cases, the milieu in which the software will run and operate. And you have to deal with the variation and vagaries and undependability of people.
And so yeah, I think the rational model is an attractive nuisance. And anytime we see somebody approaching a complex problem-solving domain with that as their ground, we should try to disabuse them of that.”
Ending where we started, check also a summary and predictions for the web development. This time, provided by Netlify, one of my favourite software, they made hosting modern web applications much easier.
Check also other links!
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.