Hacker News new | ask | show | jobs
by tom1337 15 days ago
Yea but thats not really an excuse, is it? They offer a service, (some) people pay for that service and should therefore expect it to work. If GitHub cannot keep up with the growth then they could disable new account registrations or start reducing free tiers so people either use the free tier more mindfully or need to pay for usage-base products like Actions which would GitHub allow to scale.
1 comments
hbn 15 days ago
I mean it's an easy problem to solve when it's just speculating solutions. But there's a very possible reality where in 5 years guys are making YouTube video essays about the fall of Github caused by their "obviously stupid decision" to throttle access to people who were trying to use their service in record numbers, leaving opportunity for someone else to come in and take their lunch.

I don't envy their position of having to scale that fast on something that has to be instant and real-time. As far as I know, you can't do CDN/edge caching shenanigans with a remote git repository like Google can with a YouTube video. It's gotta always be reading/writing to the latest, single source of truth.

link
tom1337 15 days ago
Sure, backseat commenting is easier and I wouldn't wanna be in charge at github right now, but on the other side there also a reality where we'd see video essays about githubs downfall because their reliability crashed so hard that businesses could not trust them and moved to competitors / self hosted instances which then meant less paid users to subsidize the ever growing demand of the free users.
link
drob518 14 days ago
It’s not quite as cacheable as YouTube, but a lot of it is still pretty cacheable. Actions aren’t. Issues, wikis, and READMEs are. File views are. Most projects aren’t changing daily. The few that change daily aren’t changing hourly. There are a few that change constantly and would require constant cache updates. But the long tail is pretty static.
link
ifwinterco 15 days ago
Yes it's potentially a write-heavy workload which also needs to be consistent aka the worst case scenario.

The easy solutions like caching and read replicas don't work and you're forced to go the route of sharding or similar techniques that have much more painful tradeoffs.

I'm not sure if that's why everything keeps breaking but at that scale write-heavy workloads are never going to be easy

link