Today, it's common to hear developers, software architects, and technical people in general talking about creating separate services to solve different needs. Creating separate services supports the independent scaling approach because it makes it possible to scale the created services separately.
The main idea, in this case, is creating separate systems that can be built and deployed independently. The source of data for these different applications can either be the same or different, depending on what the requirements are. The most common scenario here is where the same data storage is used for both systems because the applied changes should be immediately reflected. Otherwise, delayed data could cause confusion or errors during the normal operation of an application.
Let's think about an online store. Imagine that you added many items to your shopping cart, and after checking out your order, you realize you paid a lower amount of money than required because not all items were considered during the check-out process. This is undesired behavior within an application.
On the other hand, in some cases, it is okay to use different data storage because retrieving data that is delayed by hours or days is enough to solve the business needs associated with an application. Imagine that you are tasked with creating a report showing the months when people tend to request vacations. Of course, a database that does not have the latest changes, and is a bit behind the current state of the application, will work perfectly. When we have this kind of requirement, we can use reporting databases (see https://martinfowler.com/bliki/ReportingDatabase.html for more details) to retrieve the information. This approach is often taken when an application is intended to provide executive reporting information for taking strategic decisions rather than getting a list of all the existing records in the database tables.
Having separate systems to query and process information gives us the benefit of independent scaling capabilities on both systems. This is useful when one of the systems requires many more resources for processing. Let's take the example of the online store mentioned previously—people are always looking for items to buy, making comparisons, checking sizes, prices, brands, and so on.
In the preceding example, the number of requests to check out orders is less than the number of requests to check for item information. So, in this case, having separate systems allows us to avoid unnecessarily wasting resources and allows us to only add more resources or instances of the service that has the highest volume of traffic.