Imagine assigning some value to a variable, reading it back immediately after, and finding out that somehow the write had no effect at all — madness!
This is precisely what can happen when you are using a distributed data store with weak consistency guarantees. “But wait, aren’t databases supposed to take care of consistency issues for me?” I hear you ask. Whether an update becomes visible sooner rather than later depends on the guarantees offered by the database.
The system design interview is a great way to assess the seniority of a candidate in an interview. You can find a lot on the Internet on how to prepare for the design interview or which system design interview questions to expect, but very little on how to conduct an actual interview.
In this post, I will describe my experience interviewing senior candidates for distributed systems roles. …
There are two types of engineers, the ones that can quickly do estimates and the ones that can’t. Are these people just smarter, or is there more to it?
Back of the envelope estimation is a skill that can be learned with practice. It becomes easier once you get familiar with some tricks of the trade.
How fast can you read data from the disk? How quickly from the network? You should be familiar with ballpark performance figures of your components. What’s important are not the exact numbers per se but their relative differences in terms of orders of magnitude.
Why do you need to place your servers geographically close to your users? One of the reasons is to achieve lower latencies. That makes a lot of sense when you are sending short bursts of data that should be delivered as quickly as possible. But what about large files, such as videos? Surely there is a latency penalty for receiving the first byte, but shouldn’t it be smooth sailing after that?
A common misconception when sending data over TCP, like with HTTP, is that bandwidth is independent of latency. But, with TCP, bandwidth is a function of latency and time…