Single point of failure is OK... sometimes

The goal of any distributed system is to provide better availability, throughput, data durability, and other non-functional concerns, compared to functionally similar non-distributed system. Principles of distributed systems design sometimes crystallize into a short and expressive “mantras” - such as “eventually consistent” or “no single point of failure”. They are extremely useful, allowing expressing otherwise complex concepts in a short and unambiguous way, but sometimes are a little bit too broad and cover (or deny) more ground then they should. Specifically I’m talking about the “no single point of failure” principle - turns out there are many dramatically successful distributed systems that violate this principle at their core. Let’s look at what do they do instead.

Building tests - part 1

There is a well-known and widespread unit/integration/function/end-to-end taxonomy of tests that describe what is tested - single program component, single service or an entire solution. There is also a less known taxonomy of how testing is performed - from not having tests at all to the current golden standard of “single method - single test case” to a more advanced techniques - sometimes I call them “levels” of testing, as they build upon each other - like floors in a building. Interestingly, “buildings” of all heights deserve to exist as each “level” has its pros and cons - taller “buildings” are generally harder to build and maintain, but pack more inner space for the same land area - so choosing the right “height” is important for long-term success.

Pagination


© 2021 Eugeny Kolpakov. All rights reserved.

Powered by Hydejack v9.1.6