Architecture Weekly #22
Architecture Weekly Issue #22. Articles, books, and playlists on architecture and related topics. Every record has the complexity indication: ๐ค means hardcore, ๐ทโโ๏ธ is technically applicable right away, ย ๐ผ - introduction to the topic or an overview. Now in telegram as well.
WARNING ๐บ๐ฆ
It's already 3 and a half months of crazy, inhuman, unjustified war of Russia against Ukraine. We condemn this war and want it to stop ASAP. We continue this newsletter so you can advance your skill and help the millions of Ukrainian people in any way possible.
Tinder's Mobile CI/CD migration to Bazel ๐ทโโ๏ธ
Here is the success story of migration to Bazel from the Tinder team. There were many problem points before changing the Tinder iOS build system. They led to a build time of more than 40 minutes. With Bazel and a few custom tools, they achieved about 20 minutes for a build. Now it is a consistent system. Also, it is friendly for developers. But it was a difficult path for 18 months.
Microservices are services with Micro-interfaces ๐ผ
Vlad Khononov reasons about the definition of microservices and concludes that microservices should be the services with microinterfaces - as small public APIs available as possible. But then the microservice still has to grow to adhere to the complexity of a business case.
Inconsistent thoughts on database consistency ๐ทโโ๏ธ
There are too many meanings of consistency in the database world. Alex DeBrie explains what it means in CAP, ACID, and Consistency models. He discusses issues related to the consistency. Why does PACELC exist? Will ACID always help you? Are there more granular tradeoffs to consider?
A client-centric specific of Database Isolation ๐ค
If you are interested in database isolation theory, look at this paper review by Murat. It is dedicated to models which help describe and compare isolation guarantees. The main idea - use state-based formalization instead of a history-based model. It describes storage systems from an application point of view and does not base on implementation details. Also, the review by Adrian Colyer helps understand ideas clearly.
API Versioning for LinkedIn Marketing API ๐ทโโ๏ธ
Versioning for public APIs is a mandatory property to keep clients safe. Linkedin describes goals and implementation of versioning for their Marketing public API. They migrated from unversioned API to versioned API based on version headers and introduced new layers: gateway and mid-tier. Find details in the article.
Event Driven Architecture in the Real World ๐ผ
A short but nice article which demonstrates the practical examples of applying event-driven style of architecture. Diagrams, pros and cons and business needs inside.
Insights instead of Data ๐ผ
Mauro Serventi uses an analogue to the usage of a Fitness App with a band in order to monitor health. And the thing highlighted is that we don't need simple measurement history like heartbit, but we need recommendations: what to change in order to improve something in our system.
Stop calling databases CP or AP ๐ค
This article is like a preview to a chapter of Designing Data Intensive Applications. CAP theorem's definition of availability is too strong than it is actually required in a real life, so many systems can not be fully CP or AP. More details in the article.
ADR Process - AWS Prescriptive Guidance ๐ผ
ADR is one of the popular approaches to tracking architecture decisions. AWS shares guidance for the ADR process. It focuses on a few ADR goals: alignment of current and future teams, strategic directions, and avoidance of decision anti-patterns. It also pays attention to the definition of ownership. Find other best practices inside.
Identifying missing stakeholders ๐ผ
Stakeholder Management is hard though necessary for an architect job. The common problem is to fail to identify important stakeholders before the project or just doing it too late. The article by Joan Davis explains how using Enterprise Analysis and a set of techniques you can find missing stakeholders by building proper domain boundaries and understanding the relationships in the organization.
Brought to you by Vladimir @vvsevolodovich Ivanov and Ilya @puzan Zonov