EP96: A cheat sheet for system design

This week’s system design refresher: A cheat sheet for system designs Visualizing a SQL query Cloud Disaster Recovery Strategies Part-Time Opportunity: Tech Researcher & Writer at ByteByteGo Free Digital Download: The State of Streaming Data (Sponsored) Based on an independent survey of 300 streaming data-savvy tech professionals, this report shows how streaming data is used today, the size and shape of workloads, challenges, popular tools and plans for future adoption. You’ll see what your peers are doing with streaming data, including: Top concerns preventing companies from adopting streaming data Daily volume of streaming data based on workload types Data retention policies in use Core components of streaming data pipelines Top client libraries, data processing tools and formats Download the report for the full findings. Get Your Free Digital Copy A cheat sheet for system designs The diagram below lists 15 core concepts when we design systems. The cheat sheet is straightforward to go through one by one. Save it for future reference! Requirement gathering System architecture Data design Domain design Scalability Reliability Availability Performance Security Maintainability Testing User experience design Cost estimation Documentation Migration plan Visualizing a SQL query SQL statements are executed by the database system in several steps, including: Parsing the SQL statement and checking its validity Transforming the SQL into an internal representation, such as relational algebra Optimizing the internal representation and creating an execution plan that utilizes index information Executing the plan and returning the results Cloud Disaster Recovery Strategies An effective Disaster Recovery (DR) plan is not just a precaution; it's a necessity. The key to any robust DR strategy lies in understanding and setting two pivotal benchmarks: Recovery Time Objective (RTO) and Recovery Point Objective (RPO). Recovery Time Objective (RTO) refers to the maximum acceptable length of time that your application or network can be offline after a disaster. Recovery Point Objective (RPO), on the other hand, indicates the maximum acceptable amount of data loss measured in time. Let's explore four widely adopted DR strategies: Backup and Restore Strategy: This method involves regular backups of data and systems to facilitate post-disaster recovery. Typical RTO: From several hours to a few days. Typical RPO: From a few hours up to the time of the last successful backup. Pilot Light Approach: Maintains crucial components in a ready-to-activate mode, enabling rapid scaling in response to a disaster. Typical RTO: From a few minutes to several hours. Typical RPO: Depends on how often data is synchronized. Warm Standby Solution: Establishes a semi-active environment with current data to reduce recovery time. Typical RTO: Generally within a few minutes to hours. Typical RPO: Up to the last few minutes or hours. Hot Site / Multi-Site Configuration: Ensures a fully operational, duplicate environment that runs parallel to the primary system, enabling uninterrupted functionality. Typical RTO: Almost immediate, often just a few minutes. Typical RPO: Extremely minimal, usually only a few seconds old. Over to you: What factors would influence your decision to choose a DR strategy? Part-Time Opportunity: Tech Researcher & Writer at ByteByteGo, Where Your Writing Teaches Millions About ByteByteGo Newsletter: The ByteByteGo newsletter is one of the largest and fastest-growing technology newsletters in the world, with over 500,000 readers. ByteByteGo also has a social media audience of over 2 million. What You’ll Be Doing: Researching: You will delve deep into interesting tech blogs, tech talks, and insightful papers. Writing: Crafting a compelling ~2000-word blog/newsletter that covers noteworthy tech blogs, tech talks, and papers, and incorporates your thoughts. Editing: Collaborating and iterating with me to finalize the article. Requirements: Minimum 3 years of experience in building large-scale distributed systems. Passionate about explaining complex topics with simple terms. Compelling writing style. Hours: The workload is initially expected to be around 5-10 hours per week, with the potential to increase. Pays a competitive hourly rate. Perks of the Part-time Job Impact: Your work will be seen by millions of people around the world and will hopefully positively impact them. Flexibility: Enjoy flexible hours as the position is fully remote. Interested? Send your resume/LinkedIn and a sample of writing to hi@bytebytego.com We appreciate your application and assure you that we will review all submissions. Due to the number of applicants, unfortunately, we may not be able to respond to everyone. © 2024 ByteByteGo 548 Market Street PMB 72296, San Francisco, CA 94104

7 Microservices Interview Questions

7 Microservices Interview Questions Why the Internet Is Both Robust and Fragile Unlock Highly Relevant Search with AI Does Serverless Have Servers A Crash Course in Docker To receive all the full articles and support ByteByteGo, consider subscribing: Upgrade to paid Mastering Design Principles - SOLID BYTEBYTEGO JAN 25 ∙ PREVIEW READ IN APP In the fast-paced world of software development, writing robust, maintainable, and scalable code is critically important. One way to achieve this is by following a set of fundamental design principles known as the SOLID principles. These principles provide a clear framework for crafting software that is easy to understand, extend, and maintain. In this newsletter, we will explore the SOLID principles, examining each component in detail. We will review practical implementation guidance and best practices for applying them. Now, let's begin our exploration with a brief overview of the SOLID principles first. A Brief Overview The SOLID principles are a set of five fundamental design principles that were introduced by Robert C. Martin to guide software developers in creating maintainable, scalable, and flexible software systems. These principles, when followed, contribute to the development of software that is easier to understand, modify, and extend over time. Importance of Design Principles in Software Development Design principles, such as the SOLID principles, play a pivotal role in the software development process for several reasons: Maintainability: Following sound design principles makes code more maintainable. When code is well-structured and adheres to these principles, it becomes easier to identify and fix issues, add new features, and make improvements without causing unintended consequences. Scalability: Well-designed software is scalable. It can accommodate changes and growth in requirements without requiring extensive rework or becoming increasingly complex. Code Reusability: Adhering to design principles often leads to code that is more reusable. Reusable components save time and effort in development and testing. Collaboration: Design principles provide a common framework for developers to work within. This common understanding promotes collaboration and reduces misunderstandings among team members. Reduced Bugs and Pitfalls: Following design principles helps to identify and mitigate common programming pitfalls and design flaws. This results in fewer bugs and more robust software. Future-Proofing: Well-designed software can adapt to changing requirements and technologies. It's an investment in the long-term viability of the software product. Now, let's deep dive into each component of the SOLID principles. Single Responsibility Principle (SRP) The “S” in the SOLID principles stands for the Single Responsibility Principle (SRP), which states that a class should have only one reason to change or, in other words, it should have a single, well-defined responsibility or job within a software system. Illustrating a Violation of SRP Let's take a look at a Java code example below that clearly violates the Single Responsibility Principle (SRP) principle: public class Employee { private String name; private double salary; public void calculateSalary() { // definition } public void generatePayrollReport() { // definition } } In the above example, the Employee class has two responsibilities: calculating an employee's salary and generating a payroll report. This violates the SRP because it has more than one reason to change. Fixing the Violation (SRP) To address the violation of the Single Responsibility Principle (SRP) in our previous example, let's refactor the code to separate concerns and ensure that each class has a single, well-defined responsibility. We'll create distinct classes for calculating an employee's salary and generating a payroll report: public class Employee { private String name; private double salary; public void calculateSalary() { // definition } } public class PayrollReportGenerator { public void generatePayrollReport(Employee employee) { // definition } } In the refactored solution, the responsibilities of calculating the salary and generating a payroll report have been separated into two distinct classes (Employee and PayrollReportGenerator), each with a single responsibility. This adheres to the SRP. Let’s take a look at the visual representation of the classes and implementation of the single responsibility principle (SRP). Keep reading with a 7-day free trial Subscribe to ByteByteGo Newsletter to keep reading this post and get 7 days of free access to the full post archives. Start trial A subscription gets you: An extra deep dive on Thursdays Full archive Many expense it with team's learning budget LIKE COMMENT RESTACK © 2024 ByteByteGo 548 Market Street PMB 72296, San Francisco, CA 94104 Unsubscribe