So it's slow for any dynamic site? Like if I want to use it to serve a site with user generated content recommended by AI, like a reddit or twitter it's bad for that usecase?

Drupal? I think that would be very slow for that use case (if you want it to be real-time, as opposed to write-rarely-read-often, for a large number of users). I haven't tried to optimize it for that particular case, but out-of-the-box, the Acquia/Pantheon setups aren't really meant for something like that.

You could, however, use Drupal (or any other CMS) to manage the relatively infrequently-changing parts of the website (static assets, the layout, introductory text, landing pages, much of the Javascript, etc.). And then use AJAX to dynamically fetch in the dynamic portions (the user content) from some other API.

I doubt that's the best approach though... probably there are better systems for something like that. Not my specialty though, sorry =/

------

edit: It's also very different if you're operating at reddit scale vs "small website with a few dozen comments a month" scale. If you're not expecting heavy, consistent real-time traffic, it'll probably be OK. Not as fast as it could be with better architecture, but fast enough that users will put up with it. Hell, we all did it for years with phpBB, the Drupal forums, etc.

It’s great for that use case, if

- you host at one of the Drupal-optimized services (Amazee, Pantheon, Acquia)

- you put a Varnish service like Fastly in front of the site

- you use BigPipe to serve the dynamic content

- you have experienced Drupal engineers available for your project

If you’re missing one of those pieces, I’d recommend pretty strongly that you find a different platform.

What in this stack allows mass real time writes and cache invalidations?

Bigpipe looks like it chunks data from the server to the client, but it's not clear to me how that helps with real time updates to the database?

Varnish can help to a degree, but if you're on a big provider you're going through their Varnish setup anyway (among other caches) and it's not super configurable.

Drupal 8 introduced an entirely new caching system, with actually good cache invalidation. Right now if I save new content on one of my sites, it queues an invalidation request that gets sent to Varnish (which can be run either as a shutdown function or via a queue runner on cron) and the new content shows up within seconds.

I’m not sure I read the OP the same way you did. If you read it as “can I build a site on the scale of Reddit or Twitter with Drupal” then no, don’t build Reddit or Twitter with Drupal. If you read it as “will Drupal serve a site with user generated content” then yes, it will, but if you’re planning to be a top 10 site on the internet, you’ll need a custom stack.

Gotcha. Thanks for the clarification!

> if you’re planning to be a top 10 site on the internet, you’ll need a custom stack.

And yeah, that's what I thought the OP was hinting at (or at least hoping to become).

It'll handle small-medium scale forums just fine. Probably any stack would.

There's a lot of room between small- to medium-sized and Reddit-sized. Drupal 9/10 scales out well and does just fine at that large (read "enterprise") size. But certainly the more read-heavy a site is, the more suited it is to Drupal.

I have never made that to work. With Akamai we are resorting to lower ttl for cache expiry. The tag based cache architecture in practice is not helping with constraints from CDN providers

Any chance of switching to Fastly? Or at least testing it? There's excellent documentation for a working setup here: https://docs.lagoon.sh/drupal/integrate-drupal-and-fastly/ I don't know how to get invalidation working on Akamai, but the process of getting it working on another provider might get you the insight you need to get Akamai working.

> if you’re planning to be a top 10 site on the internet, you’ll need a custom stack

To be fair, that's the case with pretty much any CMS. Even if they start with a stock system, by the time they actually hit top 100/1000 (let alone 10) there's a lot of custom work to be done.

And realistically, a "top 100/1000 site" is almost always going to have a cloud of other sub-sites and related properties. The corporate site, intranet/HR, jobs and recruiting, press center... The penumbra of "Oh, yeah, we need one of those... but it would be ridiculous to build it from scratch" sites for a large organization can be pretty large indeed.