Video Transcript (English)

Data resilience is all about trade-offs—balancing the availability you need against what you're willing to invest.

There's no one-size-fits-all solution, which is why MongoDB Atlas offers a comprehensive range of options to match your specific requirements.

But how do you determine what’s essential and what’s optional?

In this video, we'll explore a real-world scenario: a fintech company designing its data resilience strategy with MongoDB Atlas.

We'll examine how to leverage Atlas features to meet each critical requirement and build a solution that's both reliable and cost-effective.

Let’s get started.

Leafy bank is a fintech company specializing in online payment processing and investment services. They have a primary mission to safeguard customer data while maintaining uninterrupted service.

As a financial company, they operate in a highly regulated environment and must comply with industry standards and ensure customer trust.

Understanding Leafy Bank’s requirements is the first step to creating a strong data resilience strategy.

So, let’s take a look at what those requirements are:

First, the ability to remain fully operational in the event of a full cloud provider region outage. This ensures continuous service for customers even during major outages.

Second, all personally identifiable information or PII must be encrypted so that only authorized users can see the data. This will require full end-to-end encryption, which includes in-transit, at-rest, and in-use.

Next, we know that Leafy Bank can tolerate losing no more than one minute of data and must restore operations within 15 minutes to minimize business disruption. This translates to a Recovery Point Objective or RPO of 1 minute and Recovery Time Objective or RTO of 15 minutes.

Finally, backups must be retained for 7 years and be immutable - no one can edit, modify, or delete backup copies. These backups must be retained in multiple locations, including a long term archival located offsite for regulatory compliance and disaster recovery.

We'll also need to balance performance and cost when determining our backup storage strategy.

Now that we understand the requirements that we need to meet, we just need to configure Atlas appropriately and MongoDB will take care of the rest.

Let’s start with the first requirement: remaining fully operational in the event of a full cloud provider region outage.

By default, every Atlas cluster includes at least three nodes in a replica set spread across different zones in a provider region.

If your primary node goes down, MongoDB automatically fails over to a secondary node in a different zone to keep your application running.

However, for protection against full region outages, we’ll choose to use a 2-2-1 node configuration using Multi-Region Data Distribution.

This will spread leafy bank’s five nodes across three different cloud regions.

We'll use a single cloud provider to simplify operations and control costs, while still achieving geographic resilience through multi-region deployment.

With this topology, even if an entire region goes offline, Atlas can still automatically fail over to one of the other regions, and leafy bank’s application can keep running without interruption for their customers.

Of course, multi-region resilience comes with trade-offs in complexity and latency that need to be carefully considered.

To configure this cluster, we’ll use the Atlas console. During setup, we'll select three cloud provider regions and specify the 2-2-1 node distribution.

Once this is done, Atlas will make life easier by replicating data, managing failover, and keeping everything synchronized automatically.

That takes care of the first requirement. Now let's look at the second: encrypting all personally identifiable information, or PII.

MongoDB Atlas comes with strong encryption built in.

All data traveling between your application and the database uses encryption in transit, and data stored on disk is automatically encrypted at rest.

But when you're handling sensitive information like PII, you need an extra layer of protection.
To do this, we can use Client-Side Field Level Encryption or CSFLE with a remote Key Management System or KMS.

CSFLE is the industry standard for this use case because it ensures sensitive fields, like Social Security numbers used for identity verification, are encrypted before they even leave Leafy Bank’s application.

This means your PII stays protected everywhere—while traveling over the network, in database memory, in storage and backups, and even in system logs.

So, while CSFLE adds complexity through key management requirements, it will deliver end-to-end encryption protecting sensitive data.

To implement CSFLE, Leafy Bank can start by identifying which fields need protection—such as social security numbers or account information—then set up encryption keys using a key management service.

Atlas provides client libraries for popular programming languages that make it easy to mark these sensitive fields for automatic encryption.

Once configured, the encryption happens seamlessly in the application layer, so developers can work with encrypted data without changing how they query or store information.

Nice work! Let’s move onto the third requirement: achieving an RPO of 1 minute and an RTO of 15 minutes or less.

Atlas makes this possible with Continuous Cloud Backups, which can be enabled while configuring a cluster.

For Leafy Bank, we can adjust our backup policy settings to retain hourly snapshots for 7 days, daily for 14 days, weekly for 8 weeks, and monthly for 7 years, satisfying multiple requirements at once.

Then, by enabling multi-region Snapshot Distribution under backup policy settings, Atlas stores backup copies in all three cluster regions. During a restore, Atlas uses the local copy in each region to get LeafyBank back online in 15 minutes or less.

We can also enable Point-in-Time recovery so that the leafy bank team can restore to any specific moment within a 7-day window, giving them up to a zero-minute RPO.

Adding continuous cloud back ups, multi-region distribution, and point-in-time recovery will increase the cost of the cluster, but will allow Leafy Bank to achieve the required RPO and RTO.

Now we have one final requirement to address: backups in Atlas need to be immutable, retained for 7 years, and have multiple copies, including a long term archival located offsite.

This presents a challenge. Retaining 7 years of operational data in the live database would significantly impact performance and escalate costs as the dataset grows over time.

The solution is a tiered data retention strategy using MongoDB Atlas Online Archive.

This feature automatically moves older, infrequently accessed data to cost-effective cloud storage while keeping it accessible for compliance and auditing needs.

Here's how this works for LeafyBank: operational data remains in the cluster for 2 years, ensuring fast backups and optimal application performance.

Cold data older than 2 years, which is still required for regulatory compliance but is rarely accessed, is automatically archived to lower-cost storage using Atlas Online Archive.

This separation prevents index bloat, maintains database performance, and reduces storage costs.

Atlas Online Archive provides an economical solution for retaining the large volumes of historical data needed for compliance without compromising the performance of active workloads.

Now for immutability…

Atlas makes this simple with the Backup Compliance Policy.

Once enabled at the project level, no user can delete backups or modify retention periods, regardless of their role.

It acts as a minimum backup schedule that all clusters must follow.

Leafy bank can configure the same retention schedule: hourly for 7 days, daily for 14, weekly for 8 weeks, and monthly for 7 years.

Once set, the policy can only be disabled through a verification process with MongoDB support by a specified contact, protecting against accidental deletion or cyberattacks.

Finally, for offsite archival, Atlas lets you export snapshots to your own S3 bucket in JSON format.

This will give leafy bank both long-term storage and complete control over their backup destiny.
Together, these features create a comprehensive data resilience strategy that keeps Leafy Bank—and your applications—running smoothly, securely, and compliantly, no matter what challenges arise.

Nice work! Let’s quickly recap the resources and tools that we used to meet Leafy bank’s requirements in this video:

Multi-Region Data and Snapshot Distribution spreads your cluster and back up copies across three regions for automatic failover during outages.

Client-Side Field Level Encryption or CSFLE protects PII by encrypting sensitive fields before they leave your application.

Continuous Cloud Backups delivers automated snapshots with Point-in-Time recovery to meet strict RPO and RTO goals.

Finally, Backup Compliance Policy ensures backups are immutable and protected from deletion or modification by any user.

While Atlas automates much of the configuration for high availability and disaster recovery, a resilient architecture still requires intentional design before production. By offloading the operational complexity of managing distributed clusters to Atlas, you can focus on the higher-level engineering tasks of optimizing security, compliance, and uptime.

To learn more about implementing these tools, visit MongoDB's documentation or explore other skill badges at MongoDB University.