System Design Classroom

System Design Classroom provides insights on building robust software systems. It discusses design patterns, best practices, and performance optimization. Themes include system independence, caching strategies, code flexibility, data organization, coupling, observer pattern, theorem updates, latency management, API testing, data structures, and system resiliency.

System Independence Caching Strategies Code Flexibility Data Organization Coupling Observer Pattern Theorem Updates Latency Management API Testing Data Structures System Resiliency

The hottest Substack posts of System Design Classroom

And their main takeaways

"Don't talk to strangers" also applies to software development.

499 implied HN points • 19 Jul 24
🕹 Technology Software Development System Design Programming Software Engineering Architecture
  1. Loose coupling is important in software. It means different parts of a program should depend on each other as little as possible, making it easier to change and fix things.
  2. The Law of Demeter suggests that objects should only talk to their direct friends and not reach out too far. This helps to keep dependencies low and makes code more manageable.
  3. Using strategies like the Single Responsibility Principle, interfaces, and dependency injection can improve your code's structure. This makes modules clear, easy to test, and maintain.

Queues offer more than orderly processing

679 implied HN points • 02 Jul 24
🕹 Technology System Design Architecture Microservices Distributed Systems Scalability
  1. Queues help different parts of a system work independently. This means you can change one part without affecting the others, making updates easier.
  2. They improve a system's ability to handle more users at once. You can add more servers to take in requests without needing to instantly boost how fast they are processed.
  3. Queues also keep things running smoothly during busy times. They act like a waiting area, holding tasks so no work gets lost even if things get too hectic.

Normalization is not enough anymore.

559 implied HN points • 23 Jun 24
🕹 Technology Database Design Data processing Software Development Performance optimization Information Systems
  1. Normalization is important for organizing data and reducing redundancy, but it's not sufficient for today's data needs. We have to think beyond just following those strict rules.
  2. De-normalization can help improve performance by reducing complex joins in large datasets. Sometimes, it makes sense to duplicate data to make queries run faster.
  3. Knowing when to de-normalize is key, especially in situations like data warehousing or when read performance matters more than write performance. It's all about balancing speed and data integrity.

Senior Developers understand Composition Over Inheritance.

599 implied HN points • 15 Jun 24
🕹 Technology Software Design Development Practices System Architecture Modularity
  1. Using composition is often better than inheritance because it allows for more flexible and maintainable code. You can mix and match simpler components to create complex systems.
  2. With composition, you can easily swap out parts of your code at runtime, making it better for projects that change frequently. It's all about keeping things modular and manageable.
  3. Though inheritance can be useful for stable hierarchies, focusing on composition is generally a safer bet, especially when you expect to make a lot of changes to your code.

"Cache me" if you can!

659 implied HN points • 01 Jun 24
🕹 Technology Software Systems Data Engineering Architecture
  1. The type of caching strategy you choose depends on your read and write ratios. If you read a lot, caching is very helpful, but if you write often, you need a more complex approach.
  2. Data consistency is crucial for some applications. Using methods like Write-Through helps keep data in cache and databases aligned, while other methods, like Write-Behind, prioritize speed over immediate consistency.
  3. To see if your caching is effective, you should track metrics like how many times data is successfully retrieved from the cache versus not retrieved. This will help you understand how well your caching is working.
Get a weekly roundup of the best Substack posts, by hacker news affinity:

Are you delivering what you promised?

279 implied HN points • 07 Jun 24
🕹 Technology Software APIs Systems Testing Performance
  1. Load tests help you see how well your API works with normal users. They show how many users it can support without slowing down.
  2. Stress tests push your API to its limits to find out what happens when it's overloaded. They help you prepare for crashes and see how fast it can recover.
  3. Spike tests check how your API handles sudden increases in traffic. They are important for making sure your service can handle bursts, especially during promotions.

Publisher + Subscribers ~ Observer Pattern

419 implied HN points • 04 May 24
🕹 Technology Software Design Patterns System Design Programming Interfaces
  1. The Observer Pattern creates a one-to-many relationship. This means when one object's state changes, all of the connected objects are notified.
  2. Components can be loosely coupled, allowing them to work together without needing to know much about each other. This makes it easy to add or change observers.
  3. Because observers can be added or removed without modifying the main subject, the system stays flexible. This helps avoid complications in your design.

Latency is a silent killer.

299 implied HN points • 16 May 24
🕹 Technology System Design Software Engineering Performance Tuning Error Handling
  1. Getting timeouts right is important. If you wait too long, your system slows down, but if you timeout too fast, you might miss a successful call.
  2. Circuit breakers help manage failures. They quickly stop requests to a failing service, allowing your system to recover faster.
  3. Bulkheads keep parts of your system separate. If one part fails, the others keep working, preventing a complete shutdown of the system.

The CAP Theorem needed an update.

359 implied HN points • 28 Apr 24
🕹 Technology Data Systems Computer Science Software Design Networking Database Management
  1. The CAP theorem says you can have consistency, availability, or partition tolerance, but only two at a time. This means systems have to make trade-offs depending on what they prioritize.
  2. The PACELC theorem expands on CAP by considering what happens during normal operation without network issues. It adds more options about choosing between latency and consistency.
  3. Real-world examples, like a multiplayer game leaderboard, show how these principles apply. You can have quick updates with potential outdated info or consistent scores that take longer to change.

HashMap is a Data Structure every SWE should know.

239 implied HN points • 24 May 24
🕹 Technology Software Data Structures Algorithms Computer Science Development
  1. Hashmaps are useful for storing data by connecting unique keys to their values, making it easy to find and retrieve information quickly.
  2. When two different keys accidentally produce the same hash code, it's called a collision. There are ways to handle this, like chaining and open addressing.
  3. Hashmaps can do lookups, insertions, and deletions really fast, usually in constant time, but they can slow down if too many items cause collisions.

Coming soon

39 implied HN points • 01 Mar 24
🚌 Education Learning Teaching Online Courses Student Engagement
  1. A new system design classroom is launching soon. It's a place to learn about designing systems.
  2. You can subscribe to get updates and learn more about system design topics.
  3. Stay tuned for more information and resources that will be available in the classroom.

Resiliency beyond the Classic Circuit Breaker

2 HN points • 10 Jul 24
🕹 Technology System Design Software Engineering Data Management APIs
  1. To handle system failures, you can use different strategies like 'Fail Fast' which stops operations quickly to save resources. But this can affect user experience because they won't get a chance to recover from the error.
  2. Another approach is 'Fail Silent', where instead of showing an error, the system quietly returns a default value. It helps keep things running smoothly, but users might miss important information if data is missing.
  3. Lastly, there's 'Custom Fallback', which uses saved local data when a service fails. This keeps the service active, but the information might be outdated, which can confuse users.