Update README.md

concepts/actors/README.md

@@ -55,7 +55,8 @@ To provide scalability and reliability, actors instances are distributed through
 
 Actors are distributed across the instances of the actor service, and those instance are distributed across the nodes in a cluster. Each service instance contains a set of actors for a given actor type.
 
-The Dapr actor runtime manages distribution scheme and key range settings for you. This is done by the actor Placement service. When a new instance of a service is created, the corresponding Dapr runtime register the actor types it can create and the Placement service calculates the partitioning across all the instances for a given actor type. This table of partition information for each actor type is updated and stored in each Dapr instance running in the environment and can change dynamically as new instance of actor services are created and destroyed. This is shown in the diagram below.
+### Actor Placement Service
+The Dapr actor runtime manages distribution scheme and key range settings for you. This is done by the actor `Placement` service. When a new instance of a service is created, the corresponding Dapr runtime register the actor types it can create and the `Placement` service calculates the partitioning across all the instances for a given actor type. This table of partition information for each actor type is updated and stored in each Dapr instance running in the environment and can change dynamically as new instance of actor services are created and destroyed. This is shown in the diagram below.
 
 ![Placement service registration](../../images/actors_placement_service_registration.png)
 
@@ -66,19 +67,19 @@ When a client calls an actor with a particular id (for example, actor id 123), t
  This simplifies some choices but also carries some consideration:
 
 * By default, actors are randomly placed into pods resulting in uniform distribution.
-* Because actors are randomly placed, it should be expected that actor operations will always require network communication, including serialization and deserialization of method call data, incurring latency and overhead.
+* Because actors are randomly placed, it should be expected that actor operations always require network communication, including serialization and deserialization of method call data, incurring latency and overhead.
 
-Note: The Dapr actor Placement service is only used for actor placement and therefore is not needed if your services are not using Dapr actors. The Placement service can run in all environments (Standalone, Kubernetes etc)
+Note: The Dapr actor Placement service is only used for actor placement and therefore is not needed if your services are not using Dapr actors. The Placement service can run in all hosting environments for example, self hosted, Kubernetes
 
 ## Actor Communication
 
-You can interact with Dapr to invoke the actor method by calling Http/gRPC endpoint
+You can interact with Dapr to invoke the actor method by calling HTTP/gRPC endpoint
 
 ```bash
 POST/GET/PUT/DELETE http://localhost:3500/v1.0/actors/<actorType>/<actorId>/<method/state/timers/reminders>
 ```
 
-You can provide any data for actor method in the request body and response for the request would be in response body which is data from actor call.
+You can provide any data for the actor method in the request body, and the response for the request would be in the response body which is the data from actor call.
 
 Refer to [Dapr Actor Features](./actors_features.md) for more details.
 
@@ -88,7 +89,7 @@ The Dapr Actors runtime provides a simple turn-based access model for accessing
 
 A single actor instance cannot process more than one request at a time. An actor instance can cause a throughput bottleneck if it is expected to handle concurrent requests.
 
-Actors can deadlock on each other if there is a circular request between two actors while an external request is made to one of the actors simultaneously. The Dapr actor runtime will automatically time out on actor calls and throw an exception to the caller to interrupt possible deadlock situations.
+Actors can deadlock on each other if there is a circular request between two actors while an external request is made to one of the actors simultaneously. The Dapr actor runtime automatically times out on actor calls and throw an exception to the caller to interrupt possible deadlock situations.
 
 !["Actor concurrency"](../../images/actors_communication.png)