Our bookstore is opening a new branch in France. To support the new language in our app, we are adding internationalization and localization support. As part of this update, the team building the site needs to change the default schema of the review documents to include a locale field. They need to make sure they don't introduce any breaking changes. In this lesson, you will learn how to handle schema evolution with MongoDB. As applications evolve, database schemas need to be updated. Whether we are introducing new features, fixing bugs, or applying new patterns, the structure of a database will change over time. This process is known as schema evolution. Sometimes a schema can change as a part of a planned update, where all stakeholders are informed and aware that changes will be made. In modern application development, it's also common for changes to happen ad hoc, after the initial schema design phase, and during development. For example, a bug fix can require us to change a schema. This can happen quickly. So all stakeholders may not be involved or aware that a change has occurred. Ad hoc updates can be very challenging if you are working with a rigid schema. But MongoDB's flexible schema model makes schema evolution very easy. Documents with different shapes can coexist in the same collection. So we can gradually evolve the schema. Then schema validation can be used to check data consistency and quality in new documents. Let's see how the schema evolves in the reviews collection. The French branch of our online bookstore app requires a new field in review documents that specifies the locale as either English or French. Legacy documents, those that are in the collection before we apply the schema change, must not break. We want to apply schema validation for all new documents. We'll be using the validation rules established for the reviews collection as a starting point. Let's take a look. First, we extend the original schema with an optional locale field. We'll use the enum keyword to specify a list of allowed values for the field. In our case, we only support the English and French locales. Once again, let's put everything together into a validator document and get ready to enable validation. We use the collMod command to enable the new schema validation for the existing reviews collection. This time, we use schema_validation_international as the validator document. And here, we supply the desired validation level and action. In this case, we want to be more relaxed in our validation approach. Since we are still in development, we'll use moderate and warn, respectively. This way legacy documents can still be modified. If we add new documents that violate the new schema validation rules, that operation will also proceed, but the violation will be recorded in the logs. Once we modify the existing schema by applying these changes, we need to test and monitor. Monitoring schema evolution is crucial to identifying schema design issues, improving data quality, and optimizing performance. Monitoring the logs is an essential element of any strategy, especially if the validation action is set to warn. But this is by no means a trivial task. Fortunately, Atlas users can benefit from schema suggestions, a built-in tool to automatically monitor your cluster and suggest schema improvements. If you were on an M10 or above cluster, Atlas schema suggestions provides out of the box schema suggestions to address common schema evolution issues and anti-patterns, including reducing $lookup operations, avoiding unbounded arrays, removing unnecessary indexes, reducing the size of large documents, reducing the number of collections, and using Atlas Search for full-text regex queries. While this feature is incredibly useful, it should only be one piece of your monitoring strategy. If you haven't already or just need a refresher, check out our monitoring content for more information. Let's do a quick recap of this lesson. Schema evolution describes changes made to your schema over time. We can easily add or update the schema validation rules for an existing collection with a collMod command. Finally, we learned that we can monitor any changes that we make to our schema for issues with MongoDB logs or Atlas schema suggestions. Great job. See you in the next lesson.