System Design - Golden Rules

1. If we are dealing with a read-heavy system, it's good to consider using a Cache to store frequently accessed data in memory, reducing database load and improving response times. Examples include Redis or Memcached.

2. If we need low latency in the system, it's good to consider using a Cache for dynamic data and a CDN for static assets like images, CSS, and JavaScript, to serve content closer to the end-user.

3. If we are dealing with a write-heavy system, it's good to use a Message Queue (e.g., RabbitMQ, Kafka, or SQS) for asynchronous processing and to decouple components for better scalability.

4. If we need a system to be ACID-compliant, we should go for an RDBMS (e.g., MySQL, PostgreSQL, or Oracle Database) to ensure transactional integrity and data consistency.

5. If data is unstructured & doesn't require ACID properties, we should go for a NoSQL Database like MongoDB, Cassandra, or DynamoDB, which provide flexible schemas and high scalability.

6. If the system has complex data in the form of videos, images, files, etc., we should go for Blob/Object storage solutions like Amazon S3, Azure Blob Storage, or Google Cloud Storage.

7. If the system requires complex pre-computation (e.g., a news feed or recommendations), we should use a combination of Message Queues for asynchronous task management and Cache for storing precomputed results.

8. If the system requires searching data in high volume, we should consider using a search index or a search engine like Elasticsearch, Apache Solr, or Algolia for full-text search and analytics.

9. If the system requires to scale SQL Database, we should consider using Database Sharding, Partitioning, or Replication to distribute data and workload effectively.

10. If the system requires High Availability, Performance, & Throughput, we should consider using a Load Balancer to distribute traffic across servers and ensure failover.

11. If the system requires faster data delivery globally, reliability, high availability, and performance, we should consider using a CDN like Cloudflare, Akamai, or AWS CloudFront.

12. If the system has data with nodes, edges, and relationships like social graphs, road networks, or recommendation engines, we should consider using a Graph Database like Neo4j or ArangoDB.

13. If the system needs scaling of various components, like servers, databases, etc., we should consider Horizontal Scaling, which adds more machines to the system rather than scaling vertically.

14. If the system requires high-performing database queries, we should use Database Indexes to improve the efficiency of SELECT statements and reduce query latency.

15. If the system requires bulk job processing, we should consider using Batch Processing frameworks like Apache Hadoop or Spark, combined with Message Queues for task distribution.

16. If the system requires reducing server load and preventing DOS attacks, we should implement a Rate Limiter using tools like NGINX, HAProxy, or libraries like Guava RateLimiter.

17. If the system has microservices, we should consider using an API Gateway for features like Authentication, SSL Termination, Routing, and Rate Limiting.

18. If the system has a single point of failure, we should implement Redundancy (e.g., multiple instances or servers) in that component to improve resilience.

19. If the system needs to be fault-tolerant and durable, we should implement Data Replication, creating multiple copies of data on different servers or regions for backup and recovery.

20. If the system needs user-to-user communication (bi-directional) in a fast way, we should use WebSockets for real-time communication.

21. If the system needs the ability to detect failures in a distributed system, we should implement a Heartbeat mechanism to monitor the health of nodes.

22. If the system needs to ensure data integrity, we should use a Checksum Algorithm like MD5 or SHA to verify the correctness of data during transmission or storage.

23. If the system needs to transfer data between servers in a decentralized way, we should use the Gossip Protocol for efficient information dissemination in distributed networks.

24. If the system needs to scale servers with the addition or removal of nodes efficiently, with no hotspots, we should implement Consistent Hashing.

25. If the system deals with location-based data, such as maps or nearby resources, we should use data structures like Quadtrees or Geohash for spatial indexing and efficient querying.

26. If the system needs event-driven architecture, consider using Event Streaming platforms like Apache Kafka or Amazon Kinesis to handle real-time data pipelines.

27. If the system requires high throughput with fault-tolerant workflows, we should consider using a Workflow Orchestration Tool like Apache Airflow or Temporal.

28. If the system involves analytics or monitoring large-scale data, we should use OLAP systems or tools like Apache Druid or ClickHouse.

29. If the system needs to ensure eventual consistency in a distributed setup, consider using Eventual Consistency Models with tools like DynamoDB or Cassandra.

30. If the system handles sensitive information, implement Encryption (both at rest and in transit) and enforce strict Access Controls.

31. If the system needs to handle unpredictable workloads, consider Auto-Scaling mechanisms to dynamically adjust resources based on demand.