Sometimes simplicity is not the best goal.

Redundancy, scalability, decoupling, resilience, best possible handling of errors, cost optimization, etc. may be more important at the scale Netflix operates at.

> Redundancy, scalability, decoupling, resilience, best possible handling of errors, cost optimization, etc. may be more important at the scale Netflix operates at.

So much that they built a tool to intentionally make things difficult (read: it arbitrarily stops production system processes/containers/etc.) and help inform what decisions to make in favor of fault tolerance.

> Exposing engineers to failures more frequently incentivizes them to build resilient services.

https://github.com/Netflix/chaosmonkey

https://en.wikipedia.org/wiki/Chaos_engineering

Embarrassing. I built 99% of Netflix functionality locally with VLC and a subdirectory of mkv files.

Good for you. Now please aim 10,000 requests a second at your file server.

I think the point was 10,000 files on 10,000 different hosts, per second.

Well, if they’re only watching one second of video that’s easy. The files could be super small too.

Okay, I can’t keep this up. I was parodying the position not being serious.

For Netflix level of complexity. Pornhub has more traffic and serves more customer than Netflix with monolithic PHP and some services.

They require completely different levels of viewing patterns and complexity. It’s such a reductionist take.

You know something about their internal architecture and why it was built that way and the tradeoffs involved, I guess?