Design patterns
Design patterns
On the importance of design patterns in software development. And how to measure and increase availability in distributed systems.
Hi Friends,
Welcome to the 10th edition of the Polymathic Engineer newsletter.
Today we will talk about:
the importance of design patterns in software development
how to measure and guarantee availability in distributed systems
coding challenge
two interesting tweets
Design Patterns
Design patterns are a crucial element in object-oriented programming, formalizing the best practices of experienced engineers. They describe general repeatable solutions to common problems, defining each solution in terms of components and their relations.
Many modern libraries and frameworks have been designed with design patterns in mind. Being familiar with these patterns can help you use them more effectively. But design patterns have many more advantages.
Here are the main benefits:
Vocabulary. Design patterns provide a common vocabulary to talk about design. If all team members are familiar with design patterns, discussions about design are more productive. They allow for conveying more information in explicit and shorter sentences.
Readability. Design patterns improve code readability. If the code uses design patterns, readers familiar with them can easily understand it.
Risk mitigation. Reusing tried and tested solutions reduce a project's technical risk and development time.
Refactoring. Design patterns make it easier to simplify the code, avoiding over-engineering during the refactoring.
Clean code. Design patterns implement design principles like SOLID. For example, the Open-Closed Principle is closely related to the decorator and strategy patterns.
There are many resources to study design patterns. Personally, I prefer these books:
• "Design Patterns: Elements of Reusable Object-Oriented Software"
• "Head First Design Patterns"
The first has almost 30 years, but it's still the reference book. The second is more digestible and suitable for beginners.
Availability
Availability is crucial for distributed systems. A few hours of downtime can cost up to $1M and affect the system's credibility. Here is how to measure and guarantee availability in a system.
Measuring availability
Availability is a measure of how a system is resistant to failures. The more a system stays operational when a component fails, its availability is higher. So availability corresponds to the percentage of time a system is functional in a specific period.
Most systems guarantee a high level of availability with all nines in percentage. For example:
• 99% = 88 hours of downtime per year
• 99.9% = 9 hours of downtime per year
• 99.99% = 53 minutes of downtime per year
• 99.999% = 6 minutes of downtime per year
Many systems require 5 nines of availability, like cloud providers, financial services, safety-critical systems, and hospital data centers.
Such systems offer explicit guarantees of availability through specific KPIs. There are 2 common KPIs: SLA (Service Level Agreement) and SLO (Service Level Objective).
An SLA is a contract between a service provider and its end users made by multiple SLOs. An SLO is a specific agreement between a service provider and its end users. Examples of SLOs are agreements like
• the system will be available 99.95% of the time
• the system will reply to 99% of requests in 3 sec
Service Level Indicators (SLIs) are metrics used to verify if the SLOs' agreements are satisfied.
Guaranteeing availability
High availability comes with trade-offs and impacts the choices during system design.
For example, increasing availability can reduce performance or data consistency. So it's essential to understand which parts of a system are critical.
The key is avoiding that a failure of some parts makes the whole system go down. Introducing redundancy is the way to minimize those single points of failure. The simple way is adding more components and replicating critical parts of the system. Everything can be replicated: servers, databases, and load balancers.
There are two types of redundancy: passive and active. Passive redundancy is when all redundant components work, and if a component dies, all the others keep working.
Active redundancy is when only some of the redundant components work. If a component dies, the others somehow know, reconfigure themselves, and start working. This process often requires a "leader election" mechanism to identify the component to step up.
Redundancy can only partially avoid failures. Some failures need to be handled by humans. Defining strictly regulated processes helps to handle failures within an acceptable timeframe.
Coding challenge
The coding challenge of last week was Palindrome Linked list. The problem asks to find if a linked list holding integer values is a palindrome or not.
The brute force solution would be to copy the linked list values into an array and check if they're palindrome using the 2-pointer method. However, this solution's time and space complexity are O(N).
Recursion provides a more elegant solution with the same asymptotic complexity. The current node and its opposite are sent down to the recursion stack. When the function returns, the algorithm compares the current node to the opposite and advances the opposite. The opposite node shall be passed by reference so that its update returns from the recursion stack. Or it can be a global variable.
The following algorithm gives a more optimized solution in terms of space:
Find the middle of the list
Reverse the 2nd half of the list
Compare the two halves of the list
Restore the list as it was (if required)
The coding challenge for the next week is Best Time to Buy and Sell Stock.
Two interesting tweets
Relationships with colleagues and networking are so underrated. I got my current job almost without interviews, thanks to an ex-teammate. You never know what can happen in the future.
This is a great thread with the most important data structure used in databases implementation. I would highly suggest to everyone to go through it in case you missed it.
