From d0a8763d5dd9b083cf11bb420d777a2f183a9211 Mon Sep 17 00:00:00 2001 From: Ebere Abanonu Date: Tue, 22 Mar 2022 15:46:10 +0100 Subject: [PATCH] Fix spelling (#5745) --- docs/articles/intro/getting-started/tutorial-1.md | 2 +- docs/articles/persistence/persistence-query.md | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/articles/intro/getting-started/tutorial-1.md b/docs/articles/intro/getting-started/tutorial-1.md index e5f7bfb3857..ce899f4840a 100644 --- a/docs/articles/intro/getting-started/tutorial-1.md +++ b/docs/articles/intro/getting-started/tutorial-1.md @@ -45,7 +45,7 @@ _supervising_ every actor living as a child of them, i.e. under their path. We will explain supervision in more detail, all you need to know now is that every unhandled failure from actors bubbles up to their parent that, in turn, can decide how to handle this failure. These predefined actors are guardians in the -sense that they are the final lines of defence, where all unhandled failures +sense that they are the final lines of defense, where all unhandled failures from user, or system, actors end up. > Does the root guardian (the root path `/`) have a parent? As it turns out, it diff --git a/docs/articles/persistence/persistence-query.md b/docs/articles/persistence/persistence-query.md index 192842a8506..cb9759bd285 100644 --- a/docs/articles/persistence/persistence-query.md +++ b/docs/articles/persistence/persistence-query.md @@ -249,11 +249,11 @@ query ## Performance and Denormalization -When building systems using Event sourcing and CQRS ([Command & Query Responsibility Segregation](https://msdn.microsoft.com/en-us/library/jj554200.aspx)) techniques it is tremendously important to realise that the write-side has completely different needs from the read-side, and separating those concerns into datastores that are optimized for either side makes it possible to offer the best experience for the write and read sides independently. +When building systems using Event sourcing and CQRS ([Command & Query Responsibility Segregation](https://msdn.microsoft.com/en-us/library/jj554200.aspx)) techniques it is tremendously important to realize that the write-side has completely different needs from the read-side, and separating those concerns into datastores that are optimized for either side makes it possible to offer the best experience for the write and read sides independently. For example, in a bidding system it is important to "take the write" and respond to the bidder that we have accepted the bid as soon as possible, which means that write-throughput is of highest importance for the write-side – often this means that data stores which are able to scale to accommodate these requirements have a less expressive query side. -On the other hand the same application may have some complex statistics view or we may have analysts working with the data to figure out best bidding strategies and trends – this often requires some kind of expressive query capabilities like for example SQL or writing Spark jobs to analyse the data. Therefore the data stored in the write-side needs to be projected into the other read-optimized datastore. +On the other hand the same application may have some complex statistics view or we may have analysts working with the data to figure out best bidding strategies and trends – this often requires some kind of expressive query capabilities like for example SQL or writing Spark jobs to analyze the data. Therefore the data stored in the write-side needs to be projected into the other read-optimized datastore. > [!NOTE] > When referring to Materialized Views in Akka Persistence think of it as "some persistent storage of the result of a Query". In other words, it means that the view is created once, in order to be afterwards queried multiple times, as in this format it may be more efficient or interesting to query it (instead of the source events directly).