Sahn Lam
@sahnlam • 48,880 subscribers
Coauthor of the Bestselling 'System Design Interview' Series | Cofounder at ByteByteGo | YouTube: https://t.co/IphBm2DLnZ
Videos
Git Merge vs. Rebase vs. Squash Commit What are the differences and when should you use each? As I explain in more detail in the video, there are some key distinctions. Git Merge This creates a new commit in the target branch. The new commit ties the histories of both main and feature branches together. Git merge is non-destructive - it introduces a new commit without altering existing ones. Git Rebase Rebase transplants commits to the tip of another branch. It creates new commits for each one moved over. The benefit is linear history. But be cautious with shared branches to avoid confusing collaborators. Squash Commit Squashing condenses multiple commits into one, streamlining the commit history. Watch the video to see when to use merge vs rebase vs squash when incorporating changes between main and feature branches. – Subscribe to our weekly newsletter to get a Free System Design PDF (158 pages):
Sahn Lam65,160 Aufrufe • vor 2 Jahren
Consistent Hashing Explained Simply Let's break down consistent hashing in a way that's easy to get. It's a handy technique for distributing data evenly across servers. And if you're more of a visual learner, don't miss the attached video which brings this concept to life. Here's how it works: We don't just hash our data keys; we also hash the server names using the same method. This puts everything on a scale, known as the hash space, which we think of as a big circular ring. So, imagine we've got a few servers. We hash them and place them on this ring. We do the same with our data, hashing it by key. To figure out where to store a piece of data, we travel clockwise on the ring from where the data lands until we bump into a server. Like, data key 0 might end up on server 0, and key 1 on server 1. Adding a new server? Only the data near the new server needs to shift. And if a server has to go? Only the data it was holding needs a new spot. But there's a little challenge: sometimes, data doesn't spread out evenly. The fix? Virtual nodes. They're like mini-replicas of a server placed around the ring. The more virtual nodes we have, the better the balance. But there's a catch: more virtual nodes mean more memory usage for tracking them, and it can make the whole system a bit more complex to manage. – Subscribe to our weekly newsletter to get a Free System Design PDF (158 pages):
Sahn Lam36,787 Aufrufe • vor 2 Jahren
Keine weiteren Inhalte verfügbar