improve

Signed-off-by: Attila Mészáros <a_meszaros@apple.com>

Author: csviri

docs/content/en/blog/news/primary-cache-for-next-recon.md

@@ -7,11 +7,12 @@ author: >-
 
 We recently released v5.1 of Java Operator SDK. One of the highlights of this release is related to a topic of so-called
 [allocated values](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#representing-allocated-values
-) in Kubernetes.
+).
 
-To sum up the problem, let's say if we create a resource from our controller that has a generated ID - 
-in other words, we cannot address the resource only by using the values from the `.spec` -
-we have to store this ID, usually in the `.status` of the custom resource. However, operator frameworks cache resources
+To describe the problem, let's say if we create a resource from our controller that has a generated ID 
+we have to store this ID, usually in the `.status` of the custom resource. 
+(In other words, we cannot address the resource only by using the values from the `.spec`.) 
+However, operator frameworks cache resources
 using informers, so the update that you made to the status of the custom resource will just eventually get into 
 the cache of the informer. If meanwhile some other event triggers the reconciliation, it can happen that we will 
 see the stale custom resource in the cache (in another word, the cache is eventually consistent) without the generated ID in the status. 
@@ -47,7 +48,7 @@ but ultimately, we only provided the solution below. (If you want to dig deep in
 
 The trick is to cache the resource from the response of our update in an additional cache on top of the informer's cache.
 If we read the resource, we first check if it is in the overlay cache and read it from there if present, otherwise read it from the cache of the informer. 
-If the informer receives an event with that resource, we always remove the resource from the overlay 
+If the informer receives an event with a fresh resource, we always remove the resource from the overlay 
 cache, since that is a more recent resource. But this **works only** if the update is done **with optimistic locking**.
 So if the update fails on conflict, we simply wait and poll the informer cache until there is a new resource version,
 and try to update again using the new resource (applied our changes again) with optimistic locking.
@@ -57,7 +58,7 @@ another party does an update on the resource just before we do. The informer rec
 if we would compare resource versions with this resource and the previously cached resource (response from our update), 
 that would be different, and in general there is no elegant way to determine if this new version that 
 informer receives an event from an update that happened before or after our update. 
-(Note that informers watch can lose connection and other edge cases)
+(Note that informer's watch can lose connection and other edge cases)
 
 
 ```mermaid
@@ -72,12 +73,11 @@ flowchart TD
 
 ```
 
-
-If we do our update with optimistic locking, it simplifies the situation, we can easily have strong guarantees.
-Since we know if the update with optimistic locking is successful, we have the fresh resource in our cache. 
+If we do our update with optimistic locking, it simplifies the situation, and we can have strong guarantees.
+Since we know if the update with optimistic locking is successful, we have the up-to-date resource in our caches. 
 Thus, the next event we receive will be the one that is the result of our update 
 (or a newer one if somebody did an update after, but that is fine since it will contain our allocated values). 
 So if we cache the resource in the overlay cache from the response, we know that with the next event, we can remove it from there.
-Note that we store the result in overlay cache only if at that time we still have the original resource in cache,
-if the cache already updated. This means that we already received a new event after our update, 
-so we have a fresh resource in the informer cache.  
+Note that we store the result in overlay cache only if at that time we still have the original resource in cache.
+If the cache already updated, that means that we already received a new event after our update, 
+so we have a fresh resource in the informer cache already.