Updated README.md

README.md

@@ -355,7 +355,7 @@ When adding a new job to a limiter, if the queue length reaches `highWater`, the
 
 ### Jobs lifecycle
 
-1. **Received**. You new job has been added to your limiter. Bottleneck needs to check whether it can be accepted into the queue.
+1. **Received**. Your new job has been added to the limiter. Bottleneck needs to check whether it can be accepted into the queue.
 2. **Queued**. Bottleneck has accepted your job, but it can not tell at what exact timestamp it will run yet, because it is dependent on previous jobs.
 3. **Running**. Your job is not in the queue anymore, it will be executed after a delay that was computed according to your `minTime` setting.
 4. **Executing**. Your job is executing its code.
@@ -829,7 +829,7 @@ It is **strongly recommended** that you give an `id` to every limiter and Group
 
 It is **strongly recommended** that you set an `expiration` (See [Job Options](#job-options)) *on every job*, since that lets the cluster recover from crashed or disconnected clients. Otherwise, a client crashing while executing a job would not be able to tell the cluster to decrease its number of "running" jobs. By using expirations, those lost jobs are automatically cleared after the specified time has passed. Using expirations is essential to keeping a cluster reliable in the face of unpredictable application bugs, network hiccups, and so on.
 
-Network latency between Node.js and Redis is not taken into account when calculating timings (such as `minTime`). To minimize the impact of latency, Bottleneck performs the absolute minimum number of state accesses. Keeping the Redis server close to your limiters will help you get a more consistent experience. Keeping the system time consistent across all clients will also help.
+Network latency between Node.js and Redis is not taken into account when calculating timings (such as `minTime`). To minimize the impact of latency, Bottleneck only performs a single Redis call per [lifecycle transition](#jobs-lifecycle). Keeping the Redis server close to your limiters will help you get a more consistent experience. Keeping the system time consistent across all clients will also help.
 
 It is **strongly recommended** to [set up an `"error"` listener](#events) on all your limiters and on your Groups.