syntax fix

docs/index.html

@@ -88,7 +88,7 @@
 <li><a href="API.en.html#api-patterns-async">Chapter 19. Asynchronicity and Time Management</a></li>
 <li><a href="API.en.html#api-patterns-lists">Chapter 20. Lists and Accessing Them</a></li>
 <li><a href="API.en.html#api-patterns-push-vs-poll">Chapter 21. Bidirectional Data Flows. Push and Poll Models</a></li>
-<li><a href="API.en.html#chapter-22">Chapter 22. </a></li>
+<li><a href="API.en.html#api-patterns-async-event-processing">Chapter 22. Multiplexing Notifications. Asynchronous Event Processing</a></li>
 <li><a href="API.en.html#chapter-23">Chapter 23. Atomicity</a></li>
 <li><a href="API.en.html#chapter-24">Chapter 24. Partial Updates</a></li>
 <li><a href="API.en.html#chapter-25">Chapter 25. Degradation and Predictability</a></li>

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

@@ -1,4 +1,4 @@
-#### [Multiplexing Notifications. Asynchronous Event Processing][api-patterns-async-event-processing]
+### [Multiplexing Notifications. Asynchronous Event Processing][api-patterns-async-event-processing]
 
 One of the vexing restrictions of almost every technology mentioned in the previous chapter is the limited size of messages. With client push notifications the situation is the most problematic: Google Firebase Messaging at the moment this chapter is being written allowed no more than 4000 bytes of payload. In backend development, the restrictions are also notable; let's say, Amazon SQS limits the size of messages to 256 KiB. While developing *webhook*-based integrations, you risk hitting the maximum body size allowed by the partner's webserver (for example, in nginx the default value is 1MB). This leads us to the necessity of making two technical decisions regarding the notification formats:
   * Whether a message contains all data needed to process it or just notifies some state change has happened