Architecture Weekly #134

Architecture Weekly Issue #134. Articles, books, and playlists on architecture and related topics. Split by sections, highlighted with complexity: 🤟 means hardcore, 👷‍♂️ is technically applicable right away,  🍼 - is an introduction to the topic or an overview. Now in telegram and Substack as well.

Intro

This is a special issue because I made significant changes to the website. First of all, the blog moved from vvsevolodovich.dev to blog.vvsevolodovich.dev. This change is a part of a bigger move: I am repurposing the main domain name to be more of a professional page, and blog is part of the content I create. Go check it out and let me know what do you think(for example, sign up for the course? Order a workshop? =)).

In order to make it happen I had to make some technical challenges, but that's worth a separate post, which will happen next week. I am also planning a big post on API Gateway purpose with examples of AWS API Gateway. Don't forget to subscribe if you're still not there!

So, it's time for the week highlights.

Highlights

Notes on Distributed Systems for Young Bloods 👷‍♂️

Unbelievably relevant article from 2013 on what is actually hard about building distributed systems and advices on what to pay attention to. Slow requests as the hardest to debug problem, partial availability, coordination issues - I beg you read carefully.

On a side note it's pretty surprising how I guessed to address the majority of those points in the course I am running. Feel free to enroll in the next cohort which starts mid-October!

Notes on Distributed Systems for Young Bloods – Something Similar

#distributedsystems

Exactly-Once Payments at Airbnb 👷‍♂️

Well, don't expect Kafka and queue semantics here, but princinples of payments processing rather and the idea that true exactly-once is technically impossible, but you can successfully fake it with idempotency keys and the mutex at the database level. More details inside.

Exactly-Once Payments At Airbnb
Eventually consistent databases make it really hard to ensure that payments are made only once. Idempotency and clever retries make it possible.

#distributedsystems #casestudy

Disaster Recovery 🍼

A year ago we had a great chat with Mikhail Druzhinin on what is a disaster in software, discussed several disaster stories and ways how to think about the disasters in the first place. I encourage you to watch the full conversation filled with stories, jokes and valuable lessons.

#video #interview

Follow-Up

Things I Wished More Developers Knew About Databases 🤟

Do you love long reads? I got you 1. 17 statements about databases you probably don't realize are true broken down in a 20 minutes read. ACID treated differently by database vendords, different isolation capabilities, anomalies, ordering problems and many more in this great article

Things I Wished More Developers Knew About Databases
A large majority of computer systems have some state and are likely to depend on a storage system. My knowledge on databases accumulated…

#db

QA myth busing: more testing - better quality

Another great piece on quality assurance by Vitaly. Not only it brings the proper mindset on the testing vs QA, but it is also based on the scientific research rather than just observations from the past experience. I especially like the take on "build your QA strategy rather than just mimicking what others are doing". Words to live by.

QA myth busting: more testing means better quality
To achieve higher quality, you need more testing, right? Not necessarily. To bust this myth, let’s explore what testing should actually aim to do.

#qa

CQRS != Read-only Database Replicas

Common misconception about CQRS pattern applied in microservices style is that it works primarily by leveraging additional replicas handling the read queries. However, this pattern is about a different data design which makes those queries efficient in the first place. Grab the explanation in the article by Yugabyte DB

CQRS != Read-Only Database Replicas
Command Query Responsibility Segregation (CQRS) is an important design pattern in microservices architectures. It separates the responsibilities of handling commands (which modify the system’s state, such as INSERT, UPDATE, DELETE) from queries (which retrieve data, typically via SELECT operations i

#db #microservices

Postgres webhooks with pgstream 👷‍♂️

CDC is well-known idea of propagating db state change through an event stream to other components but how does it look in practice? Get a nice tutorial demonstrating the data change events on Postgres through webhooks with pgstream

Postgres webhooks with pgstream
A simple tutorial for calling webhooks on Postgres data and schema changes using pgstream.

#postgres #db #cdc

Event-Driven Core 👷‍♂️

Functional code is easy to reason about due to it's purity. However pure functional product can not be used by humans, as they need to give the system instructions what to do, so you wrap it up with the imperative stuff. The same line of thoughts can be applied to event-driven vs request-response. If you wrap up an event-driven system into a request response shell you will get a nice combination. Follow the article for the details.

Event-Driven Core, Request-Response Shell
There’s much uncertainty and doubt (and maybe even fear?) around event-driven architecture. One example is the belief that it’s irrelevant for REST APIs, as using HTTP verbs is quite clearly not event-driven. But behold - you don’t always have to go all-in to win.

#eventdriven #eda

WARNING 🇺🇦

The brutal and unjustified war against Ukraine continues already 2 years. If you want to help Ukraine directly visit this fund.

Big thanks to Nikita, Constantin, Anatoly, Oleksandr, Dima, Pavel B, Pavel, Robert, Roman, Iyri, Andrey, Lidia, Vladimir, August, Roman, Egor, Roman, Evgeniy, Nadia, Daria, Dzmitry, Mikhail, Nikita, Dmytro, Denis and Mikhail for supporting the newsletter. They receive early access to the articles, videos, influence the content and participate in the closed group where we discuss the architecture problems. Join them at Patreon or Boosty!