Distributed Systems

Complete CDN design walkthrough covering architecture, edge servers, caching policies, content propagation, cache invalidation, and serving content globally at scale.

Complete key-value store design covering requirements, API design, consistent hashing, data partitioning, replication strategies, failure handling, and scaling.

Complete guide to load balancers covering algorithms (round-robin, least connections), global vs local load balancing, stateful vs stateless approaches, and scaling strategies.

Complete guide to understanding system design interviews, what interviewers expect, and how to prepare effectively for distributed systems and scalability questions.

Complete guide to consistency models covering strong consistency, eventual consistency, CAP theorem, linearizability, and trade-offs in distributed systems.

Complete guide to failure models covering crash failures, omission failures, Byzantine failures, network partitions, and fallacies of distributed systems.

Introduction to system design fundamentals covering core concepts, design principles, thinking patterns, and the philosophy behind building large-scale systems.

Complete guide to understanding DNS (Domain Name System), how it works as the internet’s phonebook, DNS architecture, and resource record types for system design interviews.

In event-driven systems, services often need to update local state and publish an event for other services. Doing these as separate operations introduces a consistency risk known as the Dual Write Problem. The core requirement is simple: the database write and event publication should represent one logical change. If one succeeds and the other fails, downstream systems may observe incomplete state. The Transactional Outbox Pattern is a practical way to address this in many microservice architectures. ...

Most good organisations expect their engineering hires to have gone through a system design interview. For a vast majority of people this might sound like a weird thing to do as most people don’t individually design large scale systems. So expecting someone to design a highly scalable and available system in less than 60 minutes is a daunting task. We must also consider the fact that not everyone gets to work in organisations that build large scale distributed systems. I think the time when I worked in FactSet was when I dealt with extremely large volumes of data and we focussed on the performance of queries from the database to sub 5 ms in order to ensure that even with latency, users would be able to see their graphs plotted in a second or so. Most applications wouldn’t really care about performance at that level because for their line business it probably doesn’t matter that much. ...