diff --git a/docs/docs/concepts/architecture/software.md b/docs/docs/concepts/architecture/software.md
index 1a82a02a21..07265b6de5 100644
--- a/docs/docs/concepts/architecture/software.md
+++ b/docs/docs/concepts/architecture/software.md
@@ -77,7 +77,7 @@ These events now are being handed down to the storage layer for storage.
 
 ZITADEL handles events in two ways. 
 Events that should be processed in near real time are processed by a in memory pub sub system.
-Some events hand be handled in background processing for which the spooler is responsible.
+Some events can be handled asynchronously using the spooler.
 
 ##### Pub Sub
 
@@ -96,7 +96,7 @@ In case of an error an event can be reapplied in two ways:
 ##### Spooler
 
 The spoolers job is it to keep a query view up-to-date or at least look that it does not have a too big lag behind the Event Store.
-Each query view has its own spooler who is responsible to look for the events who are relevant to generate the query view. It does this by triggering the relevant projection.
+Each query view has its own spooler which is responsible to look for the events who are relevant to generate the query view. It does this by triggering the relevant projection.
 Spoolers are especially necessary where someone can query datasets instead of single ids.
 
 > Each view can have exactly one spooler, but spoolers are dynamically leader elected, so even if a spooler crashes it will be replaced in a short amount of time.