- cross-posted to:
- technology@lemmy.world
- cross-posted to:
- technology@lemmy.world
cross-posted from: https://lemmy.nz/post/28397398
The suspension triggered strong responses across social media and beyond. Hashtags like #CancelDisneyPlus and #CancelHulu trended as users shared screenshots of their canceled subscriptions.
With cancellations surging, many subscribers reported technical issues. On Reddit’s r/Fauxmoi, one post read, “The page to cancel your Hulu/Disney+ subscription keeps crashing.”
“Crashes”? How convenient.
The cancellation page specifically. Everything else is fine.
On one hand, could be a “crash”. On the other hand, tons of websites break when they get a little extra traffic.
Side tangent, seems odd to me this is still a thing. Most company websites aren’t hosted on premises, so do these services like (i assume) AWS not scale for when there’s traffic? Squarespace has been advertising for years that it will scale up if there’s extra traffic. I’ve never tested it but still.
If your page is just static, e.g. no login, no interaction, everyone always sees the same thing then it scales easily. Scaling means you copy the site to more servers. Now imagine a user adds a comment. Now you need to add the comment to every copy of your site, so that everyone sees it regardless of which server they use. So a comment creates more work the more servers you use. And this is where scaling becomes a complex science, that you need to manually prepare for as a software developer. You need to figure out what data will be stored where and accessed how.
You have to design for scalability. Bottlenecks may be wherever. Even if their virtual server CPU and RAM can scale up, other stuff may be bottlenecks. Maybe the connection to the DB. Maybe the DB is elsewhere and doesn’t scale. Can’t really reasonably guess from the outside.
Mass cancellation is not usually a thing they would design around bottle-necks. It also doesn’t add value to them.
Scaling has a budget, I’m sure. They’ll only pay for so much.