Various docs edits

docs/services/eventhistory/_index.md

@@ -17,11 +17,11 @@ The `eventhistory` consumes all events from the configured event system like NAT
 
 ## Prerequisites
 
-Running the eventhistory service without an event sytem like NATS is not possible.
+Running the eventhistory service without an event system like NATS is not possible.
 
 ## Consuming
 
-The `eventhistory` services consumes all events from the configured event sytem.
+The `eventhistory` services consumes all events from the configured event system.
 
 ## Storing
 
@@ -31,10 +31,10 @@ The `eventhistory` service stores each consumed event via the configured store i
   -   `redis`: Stores data in a configured redis cluster.
   -   `etcd`: Stores data in a configured etcd cluster.
   -   `nats-js`: Stores data using key-value-store feature of [nats jetstream](https://docs.nats.io/nats-concepts/jetstream/key-value-store)
-  -   `noop`: Stores nothing. Useful for testing. Not recommended in productive enviroments.
+  -   `noop`: Stores nothing. Useful for testing. Not recommended in production environments.
 
 1.  Note that in-memory stores are by nature not reboot persistent.
-2.  Though usually not necessary, a database name and a database table can be configured for event stores if the event store supports this. Generally not applicapable for stores of type `in-memory`. These settings are blank by default which means that the standard settings of the configured store applies.
+2.  Though usually not necessary, a database name and a database table can be configured for event stores if the event store supports this. Generally not applicable for stores of type `in-memory`. These settings are blank by default which means that the standard settings of the configured store applies.
 3.  Events stay in the store for 2 weeks by default. Use `EVENTHISTORY_RECORD_EXPIRY` to adjust this value.
 4.  The eventhistory service can be scaled if not using `in-memory` stores and the stores are configured identically over all instances.