Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

System Design 101

github.com

Post reply on HN
Print view View original

41–45 of 45 posts

Re: System Design 101

#41

Post by krowek »

xwowsersx wrote: post #30

ByteByteGo seems to almost be a content generation concept for a niche market. And the thing is, aspiring developers do, apparently eat this stuff up. Thing is though, you really don't truly assimilate these concepts from a simple diagram, not just because they are gross simplifications or crude approximations — they are — but because you need to "feel" what these systems are like in a real world scenario or at least…

This seems to be a never-ending story. There are companies out there doing system design interviews to candidates with 3 years old experience and that's mostly the target of ByteByteGo. I may say, desperate people trying to digest the most they can in the less time to increase the chances of getting a job. Same as people grinding LeetCode in record time to nail a job.

BBG content is good if you want to learn about use cases and how things work if you're already in position of taking responsibilities for the implementation of technologies like those, or you have a say in your team/project. If you're never gonna work with them, then it's just reading for nothing, you'll end up forgetting those things exist.

Re: System Design 101

#42

Post by wutwutwat »

mixmastamyk wrote: post #28
wutwutwat wrote: post #16

Earlier quoted context omitted.

As I understand it, SO sites are mostly read traffic and they keep something like 2/3 of all of their data in cache at any given time. When your entire dataset is sitting in ram, you can handle insane amounts of traffic with few machines using any programming language, because most of the traffic is never even touching any code you wrote. Still impressive though! Edit: I'd be curious how they hold up to a redis `flus…

> how they hold up to a `flush all` Populate the cache as part of the startup sequence.

I was talking more about the app servers would be up and running and their cache layer would just go offline and the app servers would get 100% of the traffic. The `flush all` would be to simulate the cache going away. Populating caches on app boot is a bad idea, it'll slow the boot times, and if the cache is down, now your apps can't boot either to at least run in a degraded state. Cache should never be in the critical path like that, it's a cache, and it going away is not unexpected. Just my 2 cents.

Some cool info about SO

From 2019

> Layers of Cache at Stack Overflow

> We have our own “L1”/”L2” caches here at Stack Overflow, but I’ll refrain from referring to them that way to avoid confusion with the CPU caches mentioned above. What we have is several types of cache. Let’s first quickly cover local and memory caches here for terminology before a deep dive into the common bits used by them:

> “Global Cache”: In-memory cache (global, per web server, and backed by Redis on miss)

> Usually things like a user’s top bar counts, shared across the network

> This hits local memory (shared keyspace), and then Redis (shared keyspace, using Redis database 0)

> “Site Cache”: In-memory cache (per site, per web server, and backed by Redis on miss)

> Usually things like question lists or user lists that are per-site

> This hits local memory (per-site keyspace, using prefixing), and then Redis (per-site keyspace, using Redis databases)

> “Local Cache”: In-memory cache (per site, per web server, backed by nothing)

> Usually things that are cheap to fetch, but huge to stream and the Redis hop isn’t worth it

> This hits local memory only (per-site keyspace, using prefixing)

and

> For the curious, some quick stats from last Tuesday (2019-07-30) This is across all instances on the primary boxes (because we split them up for organization, not performance…one instance could handle everything we do quite easily):

> Our Redis physical servers have 256GB of memory, but less than 96GB used.

- 1,586,553,473 commands processed per day (3,726,580,897 commands and 86,982 per second peak across all instances – due to replicas)

- Average of 2.01% CPU utilization (3.04% peak) for the entire server (- 124,415,398 active keys (422,818,481 including replicas)

- Those numbers are across 308,065,226 HTTP hits (64,717,337 of which were question pages)

https://nickcraver.com/blog/2019/08/06/stack-overflow-how-we...

Re: System Design 101

#44

Post by mixmastamyk »

wutwutwat wrote: post #42
mixmastamyk wrote: post #28

Earlier quoted context omitted.

> how they hold up to a `flush all` Populate the cache as part of the startup sequence.

I was talking more about the app servers would be up and running and their cache layer would just go offline and the app servers would get 100% of the traffic. The `flush all` would be to simulate the cache going away. Populating caches on app boot is a bad idea, it'll slow the boot times, and if the cache is down, now your apps can't boot either to at least run in a degraded state. Cache should never be in the criti…

You have it work the way you chose, therefore not a bad idea.

Re: System Design 101

#45

Post by danielvaughn »

gtirloni wrote: post #14
danielvaughn wrote: post #4

ByteByteGo is one of the best YouTube channels I've come across. Really well done content, all explained very clearly.

I find it very shallow. Sometimes I wonder if the person presenting it actually has deep knowledge or is just reading bullet point articles.

It is indeed very shallow, especially the shorter videos. But what I love about them is that they're very valuable for anyone not familiar with the topic at hand.
Post reply on HN