What alternatives do you suggest to address the challenged posed by the above options ?

@@kedi9987 sure ### Consistent Hashing -HRW Hashing: HRW (Highest Random Weight) hashing is stateless and provides an even distribution when you lose or gain nodes. It's easier for you to explain and understand compared to Consistent Hashing. ### Leaky Bucket Algorithm 1. Token Bucket Algorithm Unlike the Leaky Bucket you might use, the Token Bucket fills up with tokens at a steady rate. You can only send data packets if a token is available, allowing you to handle bursty data better. 2. Adaptive Leaky Bucket. This is a dynamic version that adjusts the leak rate based on your network conditions. It's more adaptive and could be more efficient for your needs. 3. Priority Queuing: If you use a priority queue alongside the Leaky Bucket, you can manage different types of traffic more efficiently. High-priority packets would get processed faster. ### Tries 1. Hash Tables: If you're dealing with languages that have large alphabets, hash tables could be more memory-efficient 2. Radix Trees: Also known as compressed tries, these trees store multiple characters in a single node. This could save you some memory. 3. Variable-Length Arrays in Node: You could use variable-length arrays in each node, sorted by frequency, to save space. This is particularly useful if your trie is sparse. ### Bloom Filters 1. Cuckoo Filters. These filters allow you to remove items dynamically and offer better space efficiency. 2. Quotient Filters. These are more memory-efficient and allow you to perform more advanced set operations like union and intersection. 3. Counting Filters If you need to remove elements, Counting Filters use counters instead of bits. This could offer you more flexibility.

I agree, for system design the SOLID principles (separation of concerns), interfaces/dependency injection and unit testability are far more important than specific algorithms. These up to a point are implementation details and can always be replaced/fine tuned to data at hand (correctness first). I am not saying they are not important, but they should come second.

How will a trie eat up memory like no tomorrow? It's never going to take more space than just storing the entire set of strings by itself

@@JoseCarlosVMyup, but you have to look at the total memory footprint, including the additional overhead of the trie structure: nodes and links to child nodes, not just the strings stored themselves. Just storing 1 million unique strings of average size would occupy approximately 10 MB on their own. Regardless of whether these 1 million strings have overlapping prefixes or not, the memory overhead for the trie structure alone would be around 2 GB. Even with a 50% overlap due to common prefixes, the overhead still stands at more than 1 GB. Additionally, each node could have an array or hash map to represent transitions to child nodes, which could be mostly empty but would still take up space.

They have covered them in here beginning with consistent hashing first kzfaq.info/get/bejne/i6xpfNSezJ-YpJ8.htmlsi=8rpEiCTd3s3_V1fS

I feel exactly the same

Me too

me too

me too

Yeah, I’m gonna go looking for overly-simplistic examples of these in action, in a language I can follow…like JavaScript. I need to see implementations to really internalize the concept.

@bntheyoutube The entire premise of teaching is not going into special cases. The entire purpose of teaching a single thing is not mixing it with other stuff. Btw, if there is anybody spreading hateful stuff in the comment, it is your attitude. Don't project your inferiority complex on me, dude.

@@lucemiserlohn wtf? You seem so dumb

After Effects.

Exactly! While I was watching this video I felt like maybe in the 80s or 90s you'd need to know all this as a programmer, and you'd have read all of Knuth's books, but nowadays, libraries and existing systems do that for you. It is true, though, that understanding these will help you make the right decisions. Just like understanding a Von Neumann architecture helps you write more efficient code.

@@Misteribel well said.

Depends on the company. If you’re gonna be working on managed systems offered by Google, Aws, azure then yes you need to know these.

They will know. Trust me

​@@morenoh149can you expand on why you think they are important if you use managed systems?

I honestly think that knowing them superficially means nothing at all. You can read how much you want but the proof's in the pudding.

@@MarcoLenzo it's about being capable to go beyond the framework that you are being given. Just how we expect from Java middles+ candidates to know low-level Java and how the Spring works behind the neat annotation, the same way we expect from seniors and architects to know what kind of load balancing algos there are pros/cons, different kinds of ratelimiting and etc. If engineer is unaware of that, they will take incredibly more time to design a performant and reliable system, because thye are just thinking on a higher level of abstraction. Tbh, if person's only developing monoliths with a load of no more than 100 RPM, then those algos are likely useless for them

Quadtrees

Also, in practice, how consistent are these algorithms?

You don't have SWE experience or you are a googler, right? Because most devs don't even know these, it's just f*cking anecdotes, and generally not very good advice regarding what you should actually learn. People should start with understanding heaps, for example, not bullshit "leaky bucket" (you can derive it in 5 minutes yourself).

​@@heyman620 the movie has changed. LeetCode-style interviews are now standard, even in small companies. With five-stage interviews becoming the norm, you have to be quick and flawless in the behavioral BS as well, just to stand a chance. What was in the video some years ago sure have given applicants an edge, but now it is plain technical crap when you are up against hundreds of candidates, most of whom are thoroughly LeetCode-prepared.

​ @TheJacrespo I understand it man, just grind LeetCode - it's hard for all of us. These algos are mostly not the basics, you need to know common stuff very well. I generally think this video is bad advice. By the way, it also sucked 7+ years ago.

@@TheJacrespo I think heyman620 needs to work on their communication... but... I'm also confident they're right.

​@@TheJacrespothats absolutely the opposite of all my own experiences in the last years and all the experiences of all my real life dev friends.