Fix spelling (#5745) (#5755)

Co-authored-by: Ebere Abanonu <eaba@users.noreply.github.com>

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

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).