Live data from Hacker News

System Design 101

github.com

21–30 of 45 posts

Re: System Design 101

#21

This is bizarre. A tiny bit of information about incredibly complex subjects. And this is "interview prep" ? Like for those "consultants" that try to bluster their way into a 6 figure gig?

To be honest, these "system design" rounds are a hassle for me and even those in-depth YouTube videos don't help.

It's all so theoretical and I feel like everything I do/say is bluffing my way through them. I prefer straight algo rounds even though those are a grind.

Re: System Design 101

#22
post #10

Good Stuff, About GraphQL, I read that GraphQL is versionless, is it really versionless? If so, how? The link below says you will still need to version but we have some Graphql fans at work and they insist that it does not need to be versioned. [0] https://medium.com/swlh/no-graphql-doesnt-magically-fix-api-...

It's not versionless per se, but given you ask for the specific fields you want (e.g. user { name }), you don't have to be anal about bumping the version every time a new prop is added to a response, such as in REST, e.g. GET /users/1234 However, if you change the data schema around, like `user` is now `person` or something, or a mutation call changes the required params, there's no magic, you either update the clien…

To be fair, you don’t have this problem with REST either (any new properties can be safely ignored). Where it breaks down however (and this applies more to GraphQL because of its insistence of not being versioned) is when you want to deprecate some fields that a lot of clients depend on.

Re: System Design 101

#23

> Stack Overflow serves all the traffic with only 9 on-premise web servers, and it’s on monolith! It has its own servers and does not run on the cloud. This is contrary to all our popular beliefs these days. Love this part. I wonder how much of the complexity of microservices and various cloud services are actually adding value on a net basis vs. resume-driven development of some bored backend engineer.

Resume AND sales-driven.

It is hard to make a high-growth startup selling co-located servers whose docs page is a link to Linux documentation and RFCs.

Re: System Design 101

#24

Earlier quoted context omitted.

I also love this anecdote -- but the SO engineering team that made that possible is _not_ your average LOB engineering team in my experience. Those guys were like C#/SQL technomancers. SO is a great example of just how much is possible with a .NET monolith, but very few teams are going to be capable of driving the machines that hard.

Stackoverflow is a much simpler mostly read only, easily cacheable site compared to a workflow heavy SaaS. They're not even remotely comparable.

I think you're underestimating how much write happens in SO, and overestimating how much writes happens on 99% of the SaaS that have very few paying customers..

Re: System Design 101

#25

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

There is a dead comment in reply to the above that says that it is very shallow. Maybe it is too crudely worded, but I also have been left feeling disappointed with the ByteByteGo videos. They actually do feel more like bullet point lists. I don't mean to say it was not a lot of work to produce (especially the animations), but they are not deep dives. It could be a good resource for learning where to start, but it's…

yeah I would say I'm fairly experienced and I absolute love their gifs and images. But I find the content very shallow overall and very oriented towards passing interviews - which I believe is their goal so :)

I appreciate the gifs !

Re: System Design 101

#27
This is a great overview and explains the subjects briefly but well. I definitely was surprised by seeing a whole section dedicated to payments.

Re: System Design 101

#28

Earlier quoted context omitted.

I also love this anecdote -- but the SO engineering team that made that possible is _not_ your average LOB engineering team in my experience. Those guys were like C#/SQL technomancers. SO is a great example of just how much is possible with a .NET monolith, but very few teams are going to be capable of driving the machines that hard.

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.

Re: System Design 101

#29

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

There is a dead comment in reply to the above that says that it is very shallow. Maybe it is too crudely worded, but I also have been left feeling disappointed with the ByteByteGo videos. They actually do feel more like bullet point lists. I don't mean to say it was not a lot of work to produce (especially the animations), but they are not deep dives. It could be a good resource for learning where to start, but it's…

Its wrote memorization. Thats the teaching strategy they employ and perhaps even learned from themselves. If you asked a followup youd likely just get a rephrasing of the same thing they already said.

This is completely synonymous with “learning” in some cultures.

To be fair I think this can be a useful angle for learning but its not sufficient. Treat their newsletter like flashcards.

Re: System Design 101

#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 to have broken your teeth designing one in order for any of these ideas to truly sink in a meaningful way.

So it's sort of like...if you have the experience of having designed these types of systems or are familiar with some of these ideas from firsthand experience, the cute diagrams hold very little value. If, on the other hand, you're a new engineer, you're gobbling up these diagrams, but they don't really hold any meaning. You can't just binge on some doc that attempts to collate all system design ideas and think you've got it. Knowledge isn't acquired by "carrying books". Now, I'm not saying there might not be value in these diagrams as a refresher or tool for someone already familiar with these concepts, but it's limited to that and I suspect newer devs are being led to believe they can just memorize these diagrams and they grok these ideas. Not so.

I also cannot help but feel the author sees this area and audience as fertile ground for producing a ton of content and gaining readership - it's substack, it's blog posts...and the list goes on. I really try to avoid imputing bad motive or malintent, but I can't help but feel this is cynical in the sense that the author knows this information in this format targeting this audience does very little for them and, worse, leads them astray because of how at odds it is presented vs the way real knowledge is actually acquired.

I guess what I'm mainly saying is: beware, young devs. This ain't it.

Post reply on HN