[hotfix] [docs] Fix typos in distributed_architecture.md
diff --git a/docs/concepts/distributed_architecture.md b/docs/concepts/distributed_architecture.md
index 85b8496..8301e07 100755
--- a/docs/concepts/distributed_architecture.md
+++ b/docs/concepts/distributed_architecture.md
@@ -52,7 +52,7 @@
 
 ## Logical Co-location, Physical Separation
 
-A core principle of many Stream Processors is that application logic and the application state must be co-located. That approach is the basis for their out-of-the box consistency. Stateful Function takes a unique approach to that by *logically co-locating* state and compute, but allowing to *physically separate* them.
+A core principle of many Stream Processors is that application logic and the application state must be co-located. That approach is the basis for their out-of-the box consistency. Stateful Functions takes a unique approach to that by *logically co-locating* state and compute, but allowing to *physically separate* them.
 
   - *Logical co-location:* Messaging, state access/updates and function invocations are managed tightly together, in the same way as in Flink's DataStream API. State is sharded by key, and messages are routed to the state by key. There is a single writer per key at a time, also scheduling the function invocations.
 
@@ -67,7 +67,7 @@
 
 *Remote Functions* use the above-mentioned principle of *physical separation* while maintaining *logical co-location*. The state/messaging tier (i.e., the Flink processes) and the function tier are deployed, managed, and scaled independently.
 
-Function invocations happen through an HTTP / gRPC protocol and go through a service that routes invocation requests to any available endpoint, for example a Kubernetes (load-balancing) service, the AWS request gateway for Lambda, etc. Because invocations are self-contained (contain message, state, access to timers, etc.) the target functions can treated like any stateless application.
+Function invocations happen through an HTTP / gRPC protocol and go through a service that routes invocation requests to any available endpoint, for example a Kubernetes (load-balancing) service, the AWS request gateway for Lambda, etc. Because invocations are self-contained (contain message, state, access to timers, etc.) the target functions can be treated like any stateless application.
 
 <p class="text-center">
 	<img width="80%" src="{{ site.baseurl }}/fig/concepts/arch_funs_remote.svg"/>