What are the guidelines for architecting a website with 5000+ concurrent hits?

Question

I am developing an architecture of a website which will have more than 5000+ concurrent hits with each user possibly requiring heavy background processing. What are the guidelines for the same? Which technologies are recommended.

Answer 1

This is primarily for Java/Spring-boot

1. try to acheive horizontal scalability.
2. use JPA with L2 caching that's backed by Redis if you're doing processing
3. Utilize a cloud infrastructure to have the managed redis/serverless databases (saves you the headache)
4. When implementing your web tier, use Reactive programming platforms like Project Reactor. This will allow you to scale better with less resources.
5. Offload anything that's scheduled processing away from your main app cluster. Since the scheduler usually runs as a single instance
6. Don't put your background processing in the same nodes as your main app cluster.
7. Offload UI responsibility to the client. (i.e. just expose APIs)
8. Avoid request/response (except for authentication) and focus on subscribing to events to update the local client data. Or use something like CouchDB to synchronize data between server and device.
9. Leverage caching on the device.
10. Do not "proxy" large content, instead use a direct upload to an object store like S3 (or better use Minio to avoid vendor lock to Amazon).
11. leverage different types of data store technologies

• RDBMS (stable, easily understood, less vendor lock if using ORMs, easy to back up and restore, not as scalable for writes)
• Elastic Search (efficient searching of data, but only use it for search, vendor lock)
• Kafka (stable, harder to understand, but much more scalable, vendor lock)
• Hazelcast/MemCached/Redis (unreliable key-value stores, very very fast, super scalable, useful for sharing and caching data)
• I intentionally didn't list others like Cassandra, MongoDB as these would yield major vendor lock and harder to transfer skills.