[mewpmewp2]

Yes, I explicitly do the opposite and have the most pragmatic exercises, questions.

Another thing is an exercise for system design where hyperscaling is not required and the thing is actually quite simple. Many who have specifically prepared by leetcoding and reading "cracking the coding interview" 10 times over will naturally overengineer everything trying to fit this exercise to those book patterns dropping all common sense, all the while not having actually built anything meaningful.

I think these people will mostly try to rest and vest anyway. Truly passionate people will pass since they have actually built something and will understand the exercise.

[dmurray]

When I get a system design question I always tell the interviewer "I'd just run it on a single server with an SQLite backend, that will be plenty for the median software service and you haven't told me any numbers that suggests this needs more" and then it turns out they wanted it to run at the scale of WhatsApp.

[dallbee]

For what it's worth if I ever had a candidate give me this answer on a systems design problem I'd probably immediately stop evaluating them and start selling them on the role.

[mewpmewp2]

Usually it is expected that you ask yourself what is the expected traffic, but I usually answer with a number that technically one box could handle.

[ascar]

"So what scale are we talking about? A few million monthly users? So like hackernews? I would use a single server... "

[midasuni]

You really need two in physically different locations (ideally ASes) with some form of failover, assuming you want a reasonable guaranteed uptime

[ascar]

Does 99.995% [1] of hackernews sound reasonable enough to you?

The reality is a lot of systems (especially simple ones) run perfectly fine on a single server with next to no downtime and all the additional redundancies we introduce also add additional points of failures and without the scale that makes these necessary you might actually end up reducing your availability.

[1] https://hn.hund.io/

[kens]

> Does 99.995% [1] of hackernews sound reasonable enough to you?

How did you come up with that number? I looked at the link and just one of the outages listed on January 10 was 59 minutes. That alone makes the uptime worse than 99.99% for the entire year before it was halfway through January.

(99.995% means at most 26.3 minutes of downtime per year. See https://en.wikipedia.org/wiki/High_availability#Percentage_c...)

[ascar]

it's the 30 day uptime statistic displayed on the website I linked.

if you click the history it says 98.452% over 365 days.

[dekhn]

I can't see how hackernews is 99.995% if I get at least 30-40 "Can't serve your request" error pages a year.

[midasuni]

HN is on a pair of servers.

[ascar]

The second one is just a standby though and not in another region. And if I recall correctly dang mentioned at an outage that the failover to the standby is manual. But I'm not sure.

https://news.ycombinator.com/item?id=16076041

[borkyborkbork]

This so much this! Experience is such a wonderful thing.

[NikolaNovak]

We've run 375,000 self-service employees ERP system (so much heavier single transaction than HN) on a single (large:) db2/aix box with no downtime over last 8 years. That's well within published specs for that hardware / software combo.

Yes we do have a DR box in another data centre now, in case of meteorite or fire.

This used to be the norm. A single hardware / software box CAN be engineered for high uptime. It's perfectly fine when we choose to go the other way and distribute software over number of cheap boxes with meh software, but I get pet-peeved when people assume that's the ONLY way :).

[midasuni]

I’m paranoid about environmental situations so always have a failover, but then my DR plans include events such as “Thames barrier fails”.

[joshspankit]

Add a static caching layer and you’re ready for traffic spikes.