I am Albert Kapitanov, a seasoned software engineer with over 15+ years of experience in building robust and scalable backend systems.
Here, I write about various topics including software architecture, design patterns, best practices, and the latest trends in the tech industry.
Once upon a time, an unexpected idea struck me: what if we could integrate Proof-of-Work (POW) directly into Git commits? Let’s find out together! What is Proof-of-Work? In cryptography (and especially in cryptocurrencies), Proof-of-Work (POW) is a consensus mechanism: in order to perform a certain action (like adding a new block to the blockchain), a participant must solve a computationally intensive puzzle, thus “paying” with their computational resources. At the same time, the solution to this puzzle should be easy to verify by others. ...
The last time we spoke about the CAP theorem, we saw how it describes the trade-offs between Consistency, Availability when a system experiences a Network Partitioning. Today, we will explore another side of distributed systems trade-off: the PACELC theorem. The PACELC theorem (often pronounced as pack-else) was proposed by Daniel Abadi in 2010 as an extension to the CAP theorem. While the CAP theorem focuses only on the behavior of a distributed system during a network partition, the PACELC theorem also pays lots of attention to a different state of a system - a state without any network partitions. ...
The CAP theorem is a fundamental principle in distributed systems that every seasoned backend engineer is expected to be familiar with. But what exactly does it say — not the words but the meaning? Let’s try to derive the theorem from the ground up — and hopefully we will develop deeper understanding of the theorem. As a remark, I’d like to note: from time to time, software engineers tend to say “CAP theorem says that you can only have two out of three properties — C, A and P”. I hope that by the end of this article, you will see why this is not an accurate statement of the theorem and doesn’t really reflect its meaning. ...
When we write production-grade code, we want confidence that it behaves as expected. One of the main ways to achieve that is through unit tests — small automated checks verifying that specific parts of the code work correctly. Naturally, this raises a few questions: How many tests do we need? And how effective are they? A common answer is test coverage — a metric showing how much of the codebase is executed during testing. ...