minor corrections

src/en/clean-copy/03-[Work in Progress] Section II. The API Patterns/05.md

@@ -1,6 +1,6 @@
-### Asynchronicity and Time Management
+### [Asynchronicity and Time Management][api-patterns-async]
 
-Let's continue working with the previous example. Let's imagine that the application retrieves some system state upon start-up, perhaps not the most recent one. What else does the probability of collision depend on, and how can we lower it?
+Let's continue working with the previous example: the application retrieves some system state upon start-up, perhaps not the most recent one. What else does the probability of collision depend on, and how can we lower it?
 
 We remember that this probability is equal to the ratio of time periods: getting an actual state versus starting an app and making an order. The latter is almost out of our control (unless we deliberately introduce additional waiting periods in the API initialization function, which we consider an extreme measure). Let's then talk about the former.
 
@@ -49,9 +49,9 @@ const pendingOrders = await api.
   // → { tasks: [task] }
 ```
 
-Here we assume that task creation requires minimum checks and doesn't wait for any lingering operations and therefore is created much faster. Furthermore, this operation (of creating an asynchronous task) might be isolated as a separate backend service for performing abstract asynchronous tasks. Meanwhile, by having the functionality of creating tasks and retrieving the list of ongoing tasks we might significantly narrow the “gray zones” when clients can't learn the actual system state precisely.
+Here we assume that task creation requires minimal checks and doesn't wait for any lingering operations, and therefore, it is carried out much faster. Furthermore, this operation (of creating an asynchronous task) might be isolated as a separate backend service for performing abstract asynchronous tasks. By having the functionality of creating tasks and retrieving the list of ongoing tasks we can significantly narrow the “gray zones” when clients can't learn the actual system state precisely.
 
-Thus we naturally came to the pattern of organizing asynchronous APIs through task queues. Here we use the term “asynchronous” logically meaning the absence of mutual *logical* locks: the party that makes a request gets a response immediately and does not wait until the requested procedure is carried out fully being able to continue to interact with the API. *Technically* in modern application environments, locking (of both the client and server) almost universally doesn't happen during long-responding calls. However, *logically* allowing users to work with the API while waiting for a response from a modifying endpoint is error-prone and leads to collisions like the one we described above.
+Thus we naturally came to the pattern of organizing asynchronous APIs through task queues. Here we use the term “asynchronous” logically meaning the absence of mutual *logical* locks: the party that makes a request gets a response immediately and does not wait until the requested procedure is fully carried out being able to continue to interact with the API. *Technically* in modern application environments, locking (of both the client and server) almost universally doesn't happen during long-responding calls. However, *logically* allowing users to work with the API while waiting for a response from a modifying endpoint is error-prone and leads to collisions like the one we described above.
 
 The asynchronous call pattern is useful for solving other practical tasks as well:
   * caching operation results and providing links to them (implying that if the client needs to reread the operation result or share it with another client, it might use the task identifier to do so)
@@ -77,7 +77,7 @@ However, we must stress that excessive asynchronicity, though appealing to API d
       These issues will be totally unexpected by developers and will lead to bugs in applications that are very hard to reproduce.
   4. As a result of the above, the question of the viability of such an SLA level arises. With asynchronous tasks, it's rather easy to formally make the API uptime 100.00% — just some requests will be served in a couple of weeks when the maintenance team finds the root cause of the delay. Of course, that's not what API consumers want: their users need their problems solved *now* or at least *in a reasonable time*, not in two weeks.
 
-Therefore, despite all the advantages of the approach, we tend to recommend applying this pattern only to those cases when they are really needed (as in the example we started with when we needed to lower the probability of collisions) and having separate queues for each case. The perfect task queue solution is the one that doesn't look like a task queue. For example, we might simply make the “order creation task is accepted and awaits execution” state a separate order status, and make its identifier the future identifier of the order itself:
+Therefore, despite all the advantages of the approach, we tend to recommend applying this pattern only to those cases when they are really needed (as in the example we started with when we needed to lower the probability of collisions) and having separate queues for each case. The perfect task queue solution is the one that doesn't look like a task queue. For example, we might simply make the “order creation task is accepted and awaits execution” state a separate order status and make its identifier the future identifier of the order itself:
 
 ```
 const pendingOrders = await api.

src/ru/clean-copy/03-[В разработке] Раздел II. Паттерны дизайна API/05.md

@@ -1,4 +1,4 @@
-### Асинхронность и управление временем
+### [Асинхронность и управление временем][api-patterns-async]
 
 Продолжим рассматривать предыдущий пример. Пусть на старте приложение получает *какое-то* состояние системы, возможно, не самое актуальное. От чего ещё зависит вероятность коллизий и как мы можем её снизить?