KAFKA-15583 doc update for the "strict min ISR" rule (#18880)

Reviewers: Matthias J. Sax <[email protected]>, Dave Troiano <[email protected]>, Chia-Ping Tsai <[email protected]>

docs/design.html

@@ -382,11 +382,16 @@ <h3 class="anchor-heading"><a id="replication" class="anchor-link"></a><a href="
     <p>
     We can now more precisely define that a message is considered committed when all replicas in the ISR for that partition have applied it to their log.
     Only committed messages are ever given out to the consumer. This means that the consumer need not worry about potentially seeing a message that could be lost if the leader fails. Producers, on the other hand,
-    have the option of either waiting for the message to be committed or not, depending on their preference for tradeoff between latency and durability. This preference is controlled by the acks setting that the
+    have the option of either waiting for the message to be committed or not, depending on their preference for tradeoff between latency and durability. This preference is controlled by the <code>acks</code> setting that the
     producer uses.
-    Note that topics have a setting for the "minimum number" of in-sync replicas that is checked when the producer requests acknowledgment that a message
-    has been written to the full set of in-sync replicas. If a less stringent acknowledgement is requested by the producer, then the message can be committed, and consumed,
-    even if the number of in-sync replicas is lower than the minimum (e.g. it can be as low as just the leader).
+    Note that topics have a setting for the minimum number of in-sync replicas (<code>min.insync.replicas</code>) that is checked when the producer requests acknowledgment that a message
+    has been written to the full set of in-sync replicas. If a less stringent acknowledgment is requested by the producer, then the message is committed asynchronously across the set of in-sync replicas if
+    <code>acks=0</code>, or synchronously only on the leader if <code>acks=1</code>.
+    Regardless of the <code>acks</code> setting, the messages will not be visible to the consumers until all the following conditions are met:
+    <ol>
+        <li>The messages are replicated to all the in-sync replicas.</li>
+        <li>The number of the in-sync replicas is no less than the <code>min.insync.replicas</code> setting.</li>
+    </ol>
     <p>
     The guarantee that Kafka offers is that a committed message will not be lost, as long as there is at least one in sync replica alive, at all times.
     <p>