[kragen]

Well, as I said, you can complicate things to an arbitrary extent and make them arbitrarily inefficient, and they clearly have done so because their site went down under the load of less than a million pageviews. But the essential part of the service is delivering some HTML, JS, CSS, and images, and updating the client webpages with new flight status information, and that doesn't require 3.1 megabytes, 180 hits, a WAF, an API gateway, etc.

There's no reason FlightRadar24 has to require as much horsepower as running a WordPress site, which involves interpreting PHP (inherently inefficient, throws away 95% of your CPU power in exchange for flexibility and easy end-user programmability) and accepting user comments from a substantial fraction of users. It does require maintaining hundreds of thousands of open connections for Comet, which WordPress doesn't, but that's a manageable problem ever since kqueue landed in FreeBSD and epoll landed in Linux. It's not 01999 anymore.

Let's do an estimate of database size. 100_000 flights a day means about 32768 flights at any given time. You might get an update on each of these flights once a minute, so maybe 720 updates per flight, maybe 16 kilobytes per flight. That's 512 megabytes for the entire database. Not only can you fit that in RAM now; you can fit that in RAM on a 286 from 01987.

If the way you're accustomed to building websites results in websites that crash under light load, maybe you should consider doing it a different way rather than criticizing people who tell you there's a better way to do it.

Though I guess you missed it, I did talk about caches in my comment (edge caches with instant invalidation is the service Fastly provides), which was 626 words, less than three minutes of reading. Calling it a "walltext" makes me think you'd die of a heart attack if you ever saw a book.

[alldayeveryday]

Again, you are taking massive simplifications. Flight information is only one dataset they manage. They also manage data on planes, their users' subscriptions, perhaps site analytics, etc. The cost of the storage goes beyond the disc size - you also need redundancy, you might have offline ETL jobs to enrich the data, etc. Quoting estimates of disc size and per GB storage costs is not sufficient to summarize their costs.

Further to the point, your reply (to my comment) is not addressing my reply at all.

> unlimited traffic = unlimited cost

To support additional traffic does not come free. Sure, the traffic:cost ratio is not linear, but I don't think you are making the point that supporting the additional traffic does not have a cost associated to it? Exactly how are you refuting my comment, if you are at all?

[kragen]

Site analytics can of course grow without bound, but collecting so much site analytics you crash your site? Thats dum. Design your site so that it sheds load by not collecting so much analytics if that's a problem. And load test it before it's the most popular source of information on an international diplomatic incident.

I never quoted any estimates of disc size. I linked a server with a terabyte of RAM. Are you seriously suggesting they might have more than a terabyte of data on their users' subscriptions and on planes? Offline ETL jobs? Come on, be serious.

Redundancy? Yeah, you should have two big servers, not just one. 12 hours of FlightRadar24's revenues.

Yeah, unlimited traffic would be unlimited cost, but this is not unlimited traffic, this is US$27 of traffic that should have been US$1 of traffic. If this were 01999, or if a billion people had swarmed their site instead of less than a million, you would have a point.

[alldayeveryday]

We seem to be talking past one another, and from what I can tell you are more or less agreeing with me. Supporting additional traffic takes additional money. The estimation of the amount of money it costs to support the traffic they receive is evidence of this being the case.

Commenter > In an era of unlimited scaling infrastructure, it's a shame they're struggling to capitalize on an exclusive superbowl scale marketing event.

My Reply > Unlimited Scale = Unlimited Cost

You > estimate the cost of a limited amount of traffic

Me > wasting time talking in circles reiterating my original point

[kragen]

> That's 512 megabytes for the entire database. Not only can you fit that in RAM now; you can fit that in RAM on a 286 from 01987.

I'm an idiot, on a regular PC you can only fit that in RAM since 01999, not 01987. Not sure how I looked at "megabytes" and thought "kilobytes", since I'd just calculated it.