tforum is using NGINX (with modules), Lua, python, PHP, golang, MySQL, elasticsearch, containerization, KVM, Zen, Rust, tons of stupidly complex networking logic, and Redis. The fronts to get into tforum are in large part just containerized /d/EndGame fronts with some customization. Onionbalance is used to make a single URL.
Python is used for the Machine learning anti spam models and some simple clean up automation. No longer do we use go as I've rebuild all of those processes in rust. Everything else is about the same. The complex networking logic is a lot less complex now. Still has some... issues.
As of /u/cam3le0n's request. We heavily use redis here. When you hover over someone's name and that popup shows, that information is pulled from redis. Comment trees are generally from redis as well. The XMR price, notification amounts, also redis. Any time you think we might need to redo work on the page request to render the page generally that process is cached with redis. This site wouldn't be able to function, even with our expensive servers, without redis.
I’ve built an e-commerce site and I think I might be using Redis too much. For example, I’m saving conversations, notifications, and unread messages in it. And when a new message comes in, it automatically invalidates the cache for the other user because I set the TTL to 10 minutes. So, if A messages B, the cache for B gets invalidated as soon as A sends a new message, and it gets displayed right away.
What do you think? Is this too much, or can you never use Redis enough?
Security by obscurity is like saying we are safe unless you look in the top dark corner of the room. If you do... well the ghost will eat you alive. I believe in security from secure system designs. Things that are safe because the math proves it is.
You can always have too much cache. There is still added cost to calling it and caching things. Try to make your calls as reactive as possible. Don't just invalidate because it is easy. If the process and result doesn't change don't change the cache. If it's messaging and a notification, you can easily just tell the cache to increment it or decrease it without needing to call anything. Just have the update cache process within the message send and receiving area.
Also don't cache based on sessions. That is a common issue I see people doing. Cache based on user variables.