I’m running a lot of services off my nginx reverse proxy. This is my general setup for each subdomain - each in its own config file. I wouldn’t consider this verbose in any way - and it’s never crashed on me

service.conf

server {
    listen       443 ssl http2;
    listen  [::]:443 ssl http2;
    server_name  [something].0x-ia.moe;

    include /etc/nginx/acl_local.conf;
    include /etc/nginx/default_settings.conf;
    include /etc/nginx/ssl_0x-ia.conf;

    location / {
        proxy_pass              http://[host]:[port]/;
    }
}

nginx was built for performace, so I doubt caddy would have any significant different in regards to that. I’ve not found config verbosity to be a problem for me, but I guess to each their own. I’m aware I may come across as some gatekeeper - I assure you that is not my intention. It just feels like replacing a perfectly working, battle testing service with another one just because it’s newer is a bit of a waste of resources. Besides - you can do it yourself on your instance. It’s just a load balancer in front of a docker image.

http3 is available in nginx 1.25 if you want to run their current release.

PostgreSQL is tricky to get right and I can’t fault anyone for wanting different solution like RabbitMQ to workaround it. One of the thing I did back in the day was that when dealing with high-write traffic and the data itself is not mission critical, I would set up a tmpfs on Linux for specified amount of RAM to serves as a cache to create a duplicate of the same data table used for storing on SSD/HDD and then I create a view that combines them both where it would check the cache first before querying the HDD/SSD.

During an insert/update statement, it would trigger a condition that increment a variable (semaphore) and if reached a certain value, it would run a partitioned check on the cache table and scan for any old data that aren’t in active use based on timestamp and then have those written to HDD/SSD as well as writing to HDD/SSD if the data have been on cache long enough. Doing it this way, i was able to increase the throughput more than a 100 folds and still have data that can be retained on database.

Obviously, there are going to be some additional risks incurred by doing this like putting your data on a volatile memory although it’s less of a risk on ECC Memory on Servers. If the power goes out, whatever stored on the RAM would be gone, so I assumed in cloud they would have backup power and other solutions in place to ensure it doesn’t happen. They might have a network outage, but it’s rare for servers to do a hard fail.

I doubt it is anything that level. The problem is the data itself, in the datababase.

A reddit-like website is like email, every load from the database has unique content. You really have to be very careful when designing for scalability when almost all the data is unique.

As opposed to a site like Amazon where the listing for a toothbrush is not unqiue on every page load. There aren’t new comments and new votes altering the toothbrush listing every time a user refreshes the page. And people aren’t switching brands of toothbrush every 24 hours like the front page of Reddit abandons old data and starts with fresh data.

Caddy is not going to fix anything, on the contrary, it consumes more ram. Generally the instances have been slowing down when swap gets hit by the db, so lowering ram usage and optimizing that should be the first priority.

Switching to Caddy won’t change/fix anything.

This might be true but appservers and DBs usually give up way before nginx.

I had no idea that NGINX has Lua plugins. You’d probably want to check if Caddy has equivalents for those plugins though, or just implement them in Go yourself.