If I have a cluster with two instances, one called 'reader' and the other 'primary.' If the reader experiences a 99% spike, the primary should step in to share the load?

Hello,

1.Elastic Load Balancer (ELB): Set up an ELB to distribute incoming traffic across both the 'reader' and 'primary' instances.

2.Cross-Zone Load Balancing: Enable cross-zone load balancing on the ELB. This ensures that the ELB distributes traffic evenly across all healthy instances, regardless of the availability zone they're in.

3.Auto Scaling Group (Optional): If desired, you can still utilize an Auto Scaling Group (ASG) for managing the instances. However, in this scenario, the ELB handles the distribution of traffic, and instances can be manually or statically configured.

4.Health Checks: Configure health checks on the ELB to monitor the health of both instances. If one instance becomes unhealthy, the ELB automatically routes traffic to the healthy instance.

5.Scalability and Resilience: This setup provides scalability and resilience by automatically balancing the load across multiple instances and ensuring high availability of your application.

Learn about Elastic Load Balancing: https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html

Enable cross-zone load balancing:https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/how-elastic-load-balancing-works.html#cross-zone-load-balancing

Hlo,

If your cluster has two instances, one designated as 'reader' and the other as 'primary', and you want the 'primary' instance to step in and share the load when the 'reader' experiences a 99% spike, you'll need to implement some form of load balancing and failover mechanism.

Monitoring: Implement monitoring for both instances to track their resource utilization, such as CPU usage, memory usage, and network traffic.

Load Balancer: Set up a load balancer to distribute incoming traffic across both instances. This ensures that requests are evenly distributed and can also help with failover if one instance becomes overwhelmed. ** Auto Scaling**: Configure auto-scaling policies for your instances based on metrics like CPU utilization or request count. When the 'reader' instance experiences a spike (e.g., CPU utilization exceeds a certain threshold), auto-scaling can trigger the launch of additional instances or redistribute the load to the 'primary' instance.

Failover Mechanism: Implement a failover mechanism to redirect traffic from the 'reader' instance to the 'primary' instance when necessary. This could involve updating DNS records, reconfiguring the load balancer, or using a service discovery mechanism.

Health Checks: Configure health checks to monitor the status of each instance. If the 'reader' instance becomes unresponsive or overloaded, the health checks can trigger failover actions to route traffic to the 'primary' instance.

Graceful Degradation: Implement graceful degradation mechanisms to handle spikes in traffic gracefully, such as queuing requests or prioritizing critical tasks.

Hi

No, in a typical Amazon DocumentDB cluster configuration, the primary instance won't automatically share the load from the reader instance experiencing a spike in read traffic. Here's why:

• DocumentDB Reader Endpoint is a dedicated endpoint load balances read requests across replicas
• The reader instance itself is designed for read-only operations
• If you have more spike at read replicas You can scale your cluster horizontally by adding more read replicas.

https://docs.aws.amazon.com/documentdb/latest/developerguide/replication.html

Q: How does Amazon DocumentDB scale?

Amazon DocumentDB scales in two dimensions: storage and compute. Amazon DocumentDB's storage automatically scales from 10GB to 64 TB in increments of 10GB. Amazon DocumentDB's compute capacity can be scaled up by creating larger instances and horizontally (for greater read throughput) by adding additional replica instances (up to 15) to the cluster.