Building resilience into your architecture is one of the most effective ways to prevent technical failures from impacting your business. But how do we actually build a system that can withstand those failures? In this video, we'll explore how MongoDB's architecture is designed for resilience and high availability. We'll examine replica sets, MongoDB's distributed architecture for deployments, and strategies for handling outages and self managed environments. Let's dive in. Building resilient applications requires resilient architecture. MongoDB's design ensures high availability and data durability even during regional outages, infrastructure crashes, or provider downtime. For self managed deployments, understanding these architectural principles combined with tools like Ops Manager or Cloud Manager for observability is essential for maintaining robust, globally distributed systems. At the core of MongoDB's resilient strategy are replica sets. Each set is a group of MongoDB instances that maintain the same dataset, providing redundancy and high availability. If one node fails, others can immediately take over, minimizing downtime and preventing data loss. By distributing these replica sets across multiple regions, clouds, and availability zones, organizations can architect systems that ensure high availability regardless of where failure occurs. In more advanced replica set configurations, you could also use replica set tags to isolate certain types of workloads to specific members of a replica set. So how does that remediation phase we discussed actually look in practice? Well, it happens through automated failover. When a primary node becomes unreachable, the remaining nodes hold an election to promote a secondary node, ensuring your application stays online with minimal interruption. Let's explore a running replica set to understand its structure. We can connect to our MongoDB instance using the mongosh command seen here. Once connected, we can check the replica set status with the r s dot status command. The command returns detailed information about each member. Look for the state string field for each member. Here, we'll see values like primary, secondary, or arbiter. The output also shows health status, uptime, and replication lag, which indicates how far behind secondaries are from the primary. While replica sets provide resilience within a single location, what if you need to withstand complete regional failures or zero data loss as nonnegotiable for your business? To address this, MongoDB allows you to distribute nodes across geographic regions, cloud providers, and availability zones. Multiregion deployments distribute replica set members across separate geographic areas, protecting against regional disasters and large scale power outages, or connectivity issues affecting entire regions. If an entire region goes down, your cluster automatically fails over to nodes in another region. Multi cloud deployments spread nodes across different cloud providers like AWS, GCP, and Azure. This strategy eliminates single vendor dependency, protecting against provider specific outages and reducing vendor lock in risks. When one cloud provider experiences issues, our application continues operating using nodes on other providers. Availability zone deployments place nodes within different zones of the same cloud provider's region. Cloud providers design availability zones to be isolated from each other, which protects against localized failures like data center equipment malfunctions or zone specific connectivity issues, while keeping all nodes within a single geographic region for lower latency. Latency. For applications with regional deployment constraints, but requiring high availability, availability zone distribution offers an excellent balance. Designing resilient architecture is only effective if we verify it works during actual failures. Testing failover mechanisms ensures our deployment behaves as expected when disruptions occur. Let's simulate a primary node failure to observe MongoDB's automated failover. First, let's identify our current primary node using the "rs.status()" command. We can see the primary's host name noted here. We can simulate a failure by stopping the primary node. In self managed deployments, we can do this by connecting to the server hosting the primary and stopping the MongoDB process (shown here for Linux using the systemctl command for the systemd system and service manager). If we run the "rs.status()" command on the other node in the set, we can monitor the election. Initially, the failed primary shows as unreachable. Within seconds, remaining members detect the failure and initiate an election. Soon, a healthy secondary with the highest priority and up-to-date data becomes the new primary. During this brief period, right operations pause. But once the new primary is elected, operations resume automatically. Once testing is complete, we can restart the field node using this command. The recovered node rejoins as a secondary and catches up with the op log so it can serve reads or participate in future elections. If we were testing a multi region deployment, it's a good idea to test a complete regional failure by stopping all nodes in one region. By doing so, we can feel confident that our deployment can withstand a much larger failure scenario. These active tests are perfect for validating our resilience strategy. But for continuously monitoring it, we need dedicated observability tools. Tools like Ops Manager and Cloud Manager provide critical observability for self managed deployments. While we won't detail the configuration of these tools here, it's important to understand their role in resilience monitoring. Well done. You now have a well grounded understanding of how to build, test, and monitor resilient, self managed MongoDB deployments. First, we covered how replica sets work together to provide automated failover and data redundancy. Next, we covered MongoDB's distributed architectures, examining how multi region, multi cloud, and availability zone strategies protect our application from large scale failures. Finally, we highlighted the importance of continuous observability with tools like Ops Manager and Cloud Manager.