Java Systems Design Interview Challenger (Rafael Chinelato del Nero) (Z-Library)

Java Systems Design Interview Challenger Pass Java System Design interviews by understanding the fundamentals of a cloud system’s components. Don’t try to learn all the tools, focus on concepts instead. Rafael Chinelato del Nero This book is for sale at http://leanpub.com/java_systems_design_challenger This version was published on 2024-05-01 This is a Leanpub book. Leanpub empowers authors and publishers with the Lean Publishing process. Lean Publishing is the act of publishing an in-progress ebook using lightweight tools and many iterations to get reader feedback, pivot until you have the right book and build traction once you do. © 2024 Rafael Chinelato del Nero

Contents Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Scope and Limitations . . . . . . . . . . . . . . . . . . . . 3 Target Audience . . . . . . . . . . . . . . . . . . . . . . . . 4 Special Features . . . . . . . . . . . . . . . . . . . . . . . . 4 Systems Design Interview - How it works . . . . . . . . . 5 Author’s Credentials . . . . . . . . . . . . . . . . . . . . . . 6 1 - Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 7 How Does a Systems Design Interview Work? . . . . . . 7 Key Considerations for a Systems Design Interview . . . 7 Key Characteristics You Should Know for a Systems Design Interview . . . . . . . . . . . . . . . . . . . . 9 Components You Should Know for a Systems Design Interview . . . . . . . . . . . . . . . . . . . . . . . . . 10 Technologies You Should Know for a Systems Design Interview . . . . . . . . . . . . . . . . . . . . . . . . . 12 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2 - Fundamentals of Availability . . . . . . . . . . . . . . . 15 Why Systems Availability is Important? . . . . . . . . . . 15 Availability Legal Agreement . . . . . . . . . . . . . . . . 17 SLA – Service Level Agreement . . . . . . . . . . . . . . . 17

CONTENTS SLO – Service Level Objective . . . . . . . . . . . . . . . . 19 SLI – Service Level Indicator . . . . . . . . . . . . . . . . . 20 Nines of Availability . . . . . . . . . . . . . . . . . . . . . 21 Redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Passive redundancy . . . . . . . . . . . . . . . . . . . . . . 23 Active Redundancy . . . . . . . . . . . . . . . . . . . . . . 25 What is the Cost of Highly-Available Systems? . . . . . . 26 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 3 - Client Server Model . . . . . . . . . . . . . . . . . . . . . 30 Client-server Model Diagram . . . . . . . . . . . . . . . . 30 What is IP? . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 What is a port? . . . . . . . . . . . . . . . . . . . . . . . . 31 What is DNS? . . . . . . . . . . . . . . . . . . . . . . . . . 32 What is HTTP? . . . . . . . . . . . . . . . . . . . . . . . . 32 What Applications use the Client-server Model? . . . . . 33 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 4 - Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 IP – Internet protocol . . . . . . . . . . . . . . . . . . . . . 35 TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 HTTP Request Header . . . . . . . . . . . . . . . . . . . . 36 HTTP Methods . . . . . . . . . . . . . . . . . . . . . . . . 38 HTTP Response Codes . . . . . . . . . . . . . . . . . . . . 39 Other Internet Protocols . . . . . . . . . . . . . . . . . . . 41 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 5 - Effective API Design . . . . . . . . . . . . . . . . . . . . . 43 What is an API? . . . . . . . . . . . . . . . . . . . . . . . . 43 What is REST? . . . . . . . . . . . . . . . . . . . . . . . . . 44 API Most Used Protocols . . . . . . . . . . . . . . . . . . . 45 The API design must be defensible . . . . . . . . . . . . . 47 API Versioning . . . . . . . . . . . . . . . . . . . . . . . . . 47 Stripe API . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

CONTENTS 6 - Storage and Databases . . . . . . . . . . . . . . . . . . . 54 Computer Storage . . . . . . . . . . . . . . . . . . . . . . . 54 Data in Disk . . . . . . . . . . . . . . . . . . . . . . . . . . 55 Data in Memory . . . . . . . . . . . . . . . . . . . . . . . . 55 Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 ACID Transactions . . . . . . . . . . . . . . . . . . . . . . 56 NoSQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 CAP Theorem . . . . . . . . . . . . . . . . . . . . . . . . . 59 When to use Relational Database in a Systems Design Interview? . . . . . . . . . . . . . . . . . . . . . . . . 62 When to Use NoSQL Database in a Systems Design Interview? . . . . . . . . . . . . . . . . . . . . . . . . 62 It doesn’t support ACID. . . . . . . . . . . . . . . . . . . . 63 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 7 - Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 Reverse Proxy . . . . . . . . . . . . . . . . . . . . . . . . . 66 Forward Proxy VS Reverse Proxy . . . . . . . . . . . . . . 68 Proxy Technologies . . . . . . . . . . . . . . . . . . . . . . 70 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 8 - Latency and Throughput . . . . . . . . . . . . . . . . . . 73 Latency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 What can affect latency? . . . . . . . . . . . . . . . . . . . 73 Simulation of Latency Time for Data Reading . . . . . . . 74 Why latency is important . . . . . . . . . . . . . . . . . . 74 Throughput . . . . . . . . . . . . . . . . . . . . . . . . . . 75 Bandwidth . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 Analogy Explanation from Throughput, Latency, and Bandwidth . . . . . . . . . . . . . . . . . . . . . . . . 76 Throughput vs. Bandwidth . . . . . . . . . . . . . . . . . 77 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 9 - Load Balancer . . . . . . . . . . . . . . . . . . . . . . . . . 80 Types of Load Balancer . . . . . . . . . . . . . . . . . . . . 81 Microservices Load Balancer . . . . . . . . . . . . . . . . . 82

CONTENTS Weighted Round Robin Load balancer . . . . . . . . . . . 84 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 10 - Hashing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 What is Hashing? . . . . . . . . . . . . . . . . . . . . . . . 87 Where to Use Hashing? . . . . . . . . . . . . . . . . . . . . 88 Practical Java Hash Example . . . . . . . . . . . . . . . . . 90 Server Selection . . . . . . . . . . . . . . . . . . . . . . . . 91 Types of Hashing . . . . . . . . . . . . . . . . . . . . . . . 92 Consistent Hashing . . . . . . . . . . . . . . . . . . . . . . 94 Rendezvous Hashing . . . . . . . . . . . . . . . . . . . . . 95 SHA Detailed Explanation . . . . . . . . . . . . . . . . . . 96 Difference Between Hashing and Cryptography . . . . . 97 Reversibility . . . . . . . . . . . . . . . . . . . . . . . . . . 98 Key Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 Security Goals . . . . . . . . . . . . . . . . . . . . . . . . . 99 Difference Between Hashing and Encoding . . . . . . . . 99 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 11 - Cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 Eviction Cache Policies . . . . . . . . . . . . . . . . . . . . 103 LRU (Least Recently Used) . . . . . . . . . . . . . . . . . . 103 LRU General Use Cases . . . . . . . . . . . . . . . . . . . . 103 LRU Real-World Use Cases . . . . . . . . . . . . . . . . . . 105 Least Frequently Used (LFU) . . . . . . . . . . . . . . . . . 106 LFU General Use Cases . . . . . . . . . . . . . . . . . . . . 107 Real Use Cases from LFU . . . . . . . . . . . . . . . . . . . 109 Write Through Cache . . . . . . . . . . . . . . . . . . . . . 110 Advantages of Write-Through Cache . . . . . . . . . . . . 111 Disadvantages of Write-Through Cache . . . . . . . . . . 111 Memoization . . . . . . . . . . . . . . . . . . . . . . . . . . 112 FIFO Cache . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 LIFO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 Weighted Random Replacement (WRR) . . . . . . . . . . 115 What is stale Data? . . . . . . . . . . . . . . . . . . . . . . 115

CONTENTS Cache Technologies . . . . . . . . . . . . . . . . . . . . . . 116 Buffer VS Cache . . . . . . . . . . . . . . . . . . . . . . . . 117 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 12 - Specific Storage Paradigms . . . . . . . . . . . . . . . . 121 Blob Store . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 When to Use Blob? . . . . . . . . . . . . . . . . . . . . . . 122 Where to Store Blog Data? . . . . . . . . . . . . . . . . . . 123 Time Series DB . . . . . . . . . . . . . . . . . . . . . . . . 124 Time Series DB Technologies . . . . . . . . . . . . . . . . 126 Graph DB . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 Graph DB Technologies . . . . . . . . . . . . . . . . . . . 128 When to Use Graph DB? . . . . . . . . . . . . . . . . . . . 129 Spatial DB . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 Technologies to Use Spatial DB . . . . . . . . . . . . . . . 132 When to Use Spatial DB? . . . . . . . . . . . . . . . . . . . 134 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 13 - Database Replica and Sharding . . . . . . . . . . . . . . 138 Database Replica . . . . . . . . . . . . . . . . . . . . . . . 138 Types of Database Replica . . . . . . . . . . . . . . . . . . 139 When to Use Database Replica? . . . . . . . . . . . . . . . 141 Real World Use Cases for Database Replica . . . . . . . . 142 Technologies for Database Replica . . . . . . . . . . . . . 143 Database Sharding . . . . . . . . . . . . . . . . . . . . . . 145 Real World Use Cases for Database Sharding . . . . . . . 146 Benefits of Sharding . . . . . . . . . . . . . . . . . . . . . . 147 Challenges of Sharding . . . . . . . . . . . . . . . . . . . . 148 Types of Database Sharding . . . . . . . . . . . . . . . . . 148 Technologies for Database Sharding . . . . . . . . . . . . 150 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 14 - Leader Election . . . . . . . . . . . . . . . . . . . . . . . 153 What is Leader Election? . . . . . . . . . . . . . . . . . . . 153 Challenges of Leader Election . . . . . . . . . . . . . . . . 154 Technologies for Leader Election . . . . . . . . . . . . . . 156

CONTENTS Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 15 Peer-to-peer . . . . . . . . . . . . . . . . . . . . . . . . . . 159 What is the problem Peer-To-Peer Networks Solve? . . . 159 Solution from Peer-to-Peer Network . . . . . . . . . . . . 161 Types of Peer-to-Peer Network . . . . . . . . . . . . . . . 162 Technologies that Use Peer-to-peer . . . . . . . . . . . . . 164 Gossip Protocol . . . . . . . . . . . . . . . . . . . . . . . . 166 Gossip protocols offer several advantages in P2P networks: 167 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168 16 - Periodic Pooling and Streaming . . . . . . . . . . . . . 170 What is Periodic Pooling? . . . . . . . . . . . . . . . . . . 170 What is the Problem that Streaming Solve? . . . . . . . . 171 Technologies that Use Periodic Pooling . . . . . . . . . . . 173 How Does Streaming Work? . . . . . . . . . . . . . . . . . 174 What Is the Use Case of Streaming? . . . . . . . . . . . . 175 Technologies that Use Streaming . . . . . . . . . . . . . . 177 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 17 - Static and Dynamic Configuration . . . . . . . . . . . 180 Pros and cons of Static Configuration . . . . . . . . . . . 180 4 – Now, we can print the value of the static configuration 183 Pros and Cons of Dynamic Configuration . . . . . . . . . 183 Example of Dynamic Configuration with Java . . . . . . 185 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 18 - Rate Limiting . . . . . . . . . . . . . . . . . . . . . . . . 191 Rate Limiting Use Cases . . . . . . . . . . . . . . . . . . . 191 Rate Limiting Example with Spring . . . . . . . . . . . . . 192 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196 19 - Logging and Monitoring . . . . . . . . . . . . . . . . . . 198 Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198 Logging Best Practices . . . . . . . . . . . . . . . . . . . . 200 Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . 200

CONTENTS Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202 Tracing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204 Technologies to Use Logging and Monitoring . . . . . . . 205 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 20 - Message Broker . . . . . . . . . . . . . . . . . . . . . . . 209 Publisher . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209 Subscriber . . . . . . . . . . . . . . . . . . . . . . . . . . . 210 Topic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210 Multiple Topics . . . . . . . . . . . . . . . . . . . . . . . . 211 Message Broker Sharding . . . . . . . . . . . . . . . . . . . 212 Idempotent Operation . . . . . . . . . . . . . . . . . . . . 213 Non-idempotent operation . . . . . . . . . . . . . . . . . . 213 Deduplication . . . . . . . . . . . . . . . . . . . . . . . . . 214 Order of Messages . . . . . . . . . . . . . . . . . . . . . . . 215 Guaranteed to be Delivered at Least Once . . . . . . . . . 215 Dead-letter Queue . . . . . . . . . . . . . . . . . . . . . . . 216 Message Broker Technologies . . . . . . . . . . . . . . . . 216 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217 21 - Map Reduce . . . . . . . . . . . . . . . . . . . . . . . . . 219 Idempotent Map Reduce Operations . . . . . . . . . . . . 220 Java Map Reduce Functions . . . . . . . . . . . . . . . . . 220 Distributed File System . . . . . . . . . . . . . . . . . . . . 222 Example of Hadoop Using DFS . . . . . . . . . . . . . . . 223 Situations to Use Map-Reduce . . . . . . . . . . . . . . . . 224 Map Reduce Technologies . . . . . . . . . . . . . . . . . . 225 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . 226 22 - Security with HTTPS . . . . . . . . . . . . . . . . . . . . 228 The Problem with HTTP . . . . . . . . . . . . . . . . . . . 228 Man in the Middle Attack . . . . . . . . . . . . . . . . . . 229 HTTPS Process . . . . . . . . . . . . . . . . . . . . . . . . 231 Symmetric Encryption key . . . . . . . . . . . . . . . . . . 231 AES Symmetric Encryption . . . . . . . . . . . . . . . . . 233 Asymmetric Encryption Key . . . . . . . . . . . . . . . . . 234

CONTENTS SSL certificate (Secure socket layer) . . . . . . . . . . . . . 235 Certificate Authority . . . . . . . . . . . . . . . . . . . . . 236 Certificate Authority Examples . . . . . . . . . . . . . . . 237 TLS handshake . . . . . . . . . . . . . . . . . . . . . . . . 238 HTTPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241 23 - Design Amazon . . . . . . . . . . . . . . . . . . . . . . . 244 Ask clarifying questions . . . . . . . . . . . . . . . . . . . 244 DB Model Design . . . . . . . . . . . . . . . . . . . . . . . 246 Highlevel Systems design . . . . . . . . . . . . . . . . . . 247 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249 24 - Design Discord . . . . . . . . . . . . . . . . . . . . . . . 251 Clarifying Questions to Design Discord . . . . . . . . . . 251 Cloud Technologies for Discord . . . . . . . . . . . . . . . 252 Discord Implementation Technologies . . . . . . . . . . . 254 Basic Database model from Discord . . . . . . . . . . . . 254 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257 25 - Design Instagram . . . . . . . . . . . . . . . . . . . . . . 259 26 - Design Netflix with Java . . . . . . . . . . . . . . . . . 260 Design Netflix Clarifying Questions . . . . . . . . . . . . 261 Netflix High-LevelTechnologies Technologies . . . . . . . 263 Design Netflix DB Model . . . . . . . . . . . . . . . . . . . 264 General Technologies for Netflix Systems Design . . . . . 265 Java Technologies to Develop Netflix . . . . . . . . . . . . 266 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267 28 Next Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . 270 Recap of Key Concepts . . . . . . . . . . . . . . . . . . . . . 271 Do Interviews - Practice, Practice, Practice . . . . . . . . . 274 Join Communities and Networks . . . . . . . . . . . . . . . 275

Diversify Your Knowledge . . . . . . . . . . . . . . . . . . . 276 Seek Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . 277 Take the Challenger Developer Course . . . . . . . . . . . 278 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279

Preface The Systems Design interview is a difficult one. You need the knowledge and the strategy. You need to know how to handle it. Otherwise, the chances to pass in such an interview are very low. Even if you are knowledgeble. Understanding the fundamentals of a cloud system is a great step to be better equipped for the interview. That’s what we will see in this book, also, we will explore strategies to pass in this interview more easily. Motivation The Systems Design interview is very popular nowadays. This happened because the big companies are doing that with candidates and as it commonly happens, all the other companies are doing the same for interviews. Therefore, studying Systems Design makes you a better software engineer and also prepares you for a job interview. Another motivation to write this book is to show you that failing in this interview doesn’t mean we are bad software engineers. It means that we don’t know how the game is played and to beat any game, we need to know the rules. In this book I will show you the rules of the game and also the fundamental knowledge you need to be able to learn technologies much faster. To be a fast learner in the area of software develop- ment is crucial because new technologies are launched every day. Since our brains have many neuroconnections when we have the basic knowledge of any subject, our brains make the connection

Preface 2 much faster. That’s why mastering the fundamentals is powerful. We make the connections very fast because all technologies are actually based on fundamentals. Objectives The main objective of this book is to give you a solid foundational knowledge about Systems Design so you can learn any new tech- nology faster. Programmers are not what the market wants anymore. Nowadays, companies are looking for software engineers, this means, a de- veloper who can analyze a problem and come up with effective solutions. The ability of articulating a solution, creating good quality code, talking to coworkers, preparing documentation with architecture solutions, designing database, create performant and scalable sys- tems are the skills companies are looking for. Some years ago, knowing a Java framework was enough for the market but the scenario has changed. That’s why themost powerful skill any software can have is the ability to learn, the ability to be a software engineer. If you study a little bit the life of one of the greatest engineers on history, Leonardo da Vinci, you will realize that one of his most powerful traits was his curiosity. He was curious on understanding even why we yawn when we are sleepy. As Da Vinci, we need to have a similar mindset, we need to be curious about technologies and at the same time focused. Because we don’t really have time to learn random things, we want to spend quality time with our families and deliver high-quality work. Therefore, keep that in mind, be curious to learn, never think you know everything that will never happen. We have to accept that in

Preface 3 our profession more than others we will learn our whole life. We must see that as a good thing because if we are learning something new it means we are alive. If we stop learning we are dying, there is nothing else to do in life. Keep this mantra, Never Stop Learning. Scope and Limitations We will explore the most important fundamentals of Systems Design. We will see: • Concepts and technologies to make services communicate with the client • Technologies to make Microservices scalable • Manipulating data in the database • Ways to debug and monitor cloud services • How to make Microservices resilient to failure • How to make Microservices performant • How to make data transfering fast for special cases • How to make Microservices more secure • Techniques and technologies to handle Big Data Notice that it’s impossible to explain all of those topics in dept in just one book. For most of those technologies andconcepts we would be able to create a whole book. However, remember that it’s impossible to know all of those technologies in depth, we just need to know approximately 20% so we can solve 80% of the problems. Don’t think you must know all of those technologies because that will never happen. We must keep in mind that it’s useless to know all of those technologies in depth, instead, wemust know enough of them sowe can solve important problems, so we can create something useful.

Preface 4 Otherwise, there is no point on learning a lot and applying nothing. Always learn something with an action in mind. Target Audience Systems Design is a complex topic because it involves understand- ing systems as a whole. Therefore, this book was created mostly for intermediate or senior developers. However, this book can be consumed by developers who are begginers also because we explore a lot of fundamental knowledge that can be learned without prior knowledge. Even if the Systems Design interview is not something a begginer developer will do, it’s good to know their principles. Special Features Unlike the other Systems Design books, this book is more focused on doing Systems Design with Java. Therefore, you will see Java as much as possible in the book. Java has a huge ecosystem and has many technologies to use in the cloud. The frameworks Spring, Quarkus, Micronaut and others are highly focused on the cloud. Some of the Systems Design principles will mention those technologies since in most companies they will be used. However, behind those technologies there are the Systems Design principles and that’s what we will focus on.

Systems Design Interview - How it works During the Systems Design interview we will need to design a system with a vague information such as “design Amazon”, or “design Netflix”, or “design Discord”. To accomplish that we need to have the basic knowledge of how systems work. Other than that, we must assume we will design the application in the simplest way in our questions because usually in a Systems Design interview we have only 45 minutes. We also have to understand what we are designing, we can’t start designing the system in a complicated way without making the right questions, that will make us fail right away. Instead, we make strategic questions to make the System design simple and always ask the interviewer for feedback to understand if the design is correct. To have a general understanding of this process, let’s see how we would design some applications we use in our day-to-day lives. We also need the fundamental knowledge of the parts of a system. In the book we will explore first the fundamentals and then in the last chapters we will see how e can explore famous systems.

Author’s Credentials Rafael del Nero is a Java Champion with more than 15 years of experience as a software engineer. He moved from Brazil Sao Paulo to Dublin in Ireland in 2017 to work as a software engineer in Europe. He worked mostly with Java, Spring and Jakarta EE with cloud projects. He worked with highly-skilled software engineers so he could learn key techniques to help you to become also a highly-skilled software engineer. Rafael is non-stop learner and his focus is to help Java developers to earn more and work less so they enjoy high-quality time with their families.

1 - Introduction The Systems design interview became very popular in the market nowadays. After the big techs Google, Meta, Microsoft, Amazon and other companies started using it, all the other companies are doing the same. That’s why knowing how the systems design interview works is key for you to get a good job. How Does a Systems Design Interview Work? The interviewee will give you a vague question such as design Youtube or design Instagram, then it’s up to you to make the right questions to explain how you will build the system. It’s very important to assumewhat the system should be like, there- fore, every question youmake assume the simplest. Remember that on those interviews youwill have something around 1 hour. Accept that you won’t be able to create a very robust system in this but it will be enough to get your knowledge tested on the subject. Depending on what you decide to use on the Systems Design inter- view, you might be challenged by the interviewer to explain why you made that technology choice. If you talk about a technology, it’s better for you to pick one that you know very well. Differently than the algorithms interview, the answer you give to build a system is subjective. This means you will have to know why you choose the technologies and what are the trade offs.

1 - Introduction 8 Key Considerations for a Systems Design Interview In a Systems Design interview, there are several key considerations that you should focus on. These considerations demonstrate your understanding of building scalable, performant, reliable, and secure systems. Here are some important design considerations: Scalability: How will the system handle a growing number of users, data, and traffic? Consider horizontal scaling, load balanc- ing, and partitioning strategies. Performance: How will the system handle high volumes of con- current requests? Consider optimizing database queries, caching strategies, content delivery networks (CDNs), and efficient use of resources. Reliability: How will the system ensure high availability and fault tolerance? Consider redundancy, replication, failover mechanisms, and disaster recovery strategies. Security: How will the system protect user data, prevent unau- thorized access, and mitigate potential vulnerabilities? Consider authentication, authorization, encryption, secure API endpoints, and protection against common attacks like cross-site scripting (XSS) and SQL injection. Data storage and retrieval: How will user-generated content be stored and retrieved efficiently? Consider database choices, data partitioning, indexing strategies, and caching mechanisms. Data consistency: How will the system maintain data consistency across different components and replicas? Consider consistency models, distributed transactions, and conflict resolution strategies. Communication and messaging: How will different components of the system communicate with each other? Consider message

1 - Introduction 9 queues, pub-sub systems, event-driven architectures, and commu- nication protocols. Third-party integrations: How will the system integrate with external services or APIs? Consider authentication, rate limiting, and handling failures or API changes. Analytics and monitoring: How will the system collect and analyze user activity data? Consider logging, monitoring, and analytics tools to gain insights into system performance and user behavior. Cost optimization: How will the system optimize costs associated with infrastructure, storage, and data transfer? Consider efficient resource utilization, auto-scaling, and leveraging cloud services. These considerations will help you demonstrate a holistic under- standing of system design principles and showcase your ability to design robust and scalable solutions. Remember to prioritize these considerations based on the specific requirements and constraints of the system you are designing. Key Characteristics You Should Know for a Systems Design Interview You will need to make the necessary questions to understand what you will want to prioritise for your system. Usually, the system you will design will be a cloud system. Nowa- days, you have to keep in mind all of the following system charac- teristics: Availability: Availability refers to the ability of a system or service to remain operational and accessible without interruptions. High availability is important for critical systems used in healthcare, finance, and transportation, and is achieved through redundancy, failover mechanisms, and other strategies that minimize downtime.