Doc: Add topic and expand info for in-memory queue

docs/index.asciidoc

@@ -178,6 +178,9 @@ include::static/filebeat-modules.asciidoc[]
 :edit_url: https://github.com/elastic/logstash/edit/{branch}/docs/static/resiliency.asciidoc
 include::static/resiliency.asciidoc[]
 
+:edit_url: https://github.com/elastic/logstash/edit/{branch}/docs/static/mem-queue.asciidoc
+include::static/mem-queue.asciidoc[]
+
 :edit_url: https://github.com/elastic/logstash/edit/{branch}/docs/static/persistent-queues.asciidoc
 include::static/persistent-queues.asciidoc[]
 

docs/static/mem-queue.asciidoc

@@ -0,0 +1,51 @@
+[[memory-queue]]
+=== Memory queue 
+
+By default, Logstash uses in-memory bounded queues between pipeline stages (inputs → pipeline workers) to buffer events. 
+If Logstash experiences a temporary machine failure, the contents of the memory queue will be lost. 
+Temporary machine failures are scenarios where Logstash or its host machine are terminated abnormally, but are capable of being restarted. 
+
+[[mem-queue-benefits]]
+==== Benefits of memory queues
+
+The memory queue might be a good choice if you value throughput over data resiliency. 
+
+* Easier configuration
+* Easier management and administration
+* Faster throughput
+
+[[mem-queue-limitations]]
+==== Limitations of memory queues
+
+* Can lose data in abnormal termination
+* Don't do well handling sudden bursts of data, where extra capacity in needed for {ls} to catch up
+* Not a good choice for data you can't afford to lose
+
+TIP: Consider using <<persistent-queues,persistent queues>> to avoid these limitations. 
+
+[[sizing-mem-queue]]
+==== Memory queue size
+
+Memory queue size is not configured directly.
+Multiply the `pipeline.batch.size` and `pipeline.workers` values to get the size of the memory queue.
+This value is called the "inflight count." 
+
+[[backpressure-mem-queue]]
+==== Back pressure
+
+When the queue is full, Logstash puts back pressure on the inputs to stall data
+flowing into Logstash. 
+This mechanism helps Logstash control the rate of data flow at the input stage
+without overwhelming outputs like Elasticsearch.
+
+ToDo: Is the next paragraph accurate for MQ? 
+
+Each input handles back pressure independently. 
+For example, when the
+<<plugins-inputs-beats,beats input>> encounters back pressure, it no longer
+accepts new connections.
+It waits until the queue has space to accept more events. 
+After the filter and output stages finish processing existing
+events in the queue and ACKs them, Logstash automatically starts accepting new
+events.
+

docs/static/resiliency.asciidoc

@@ -1,6 +1,8 @@
 [[resiliency]]
 == Data resiliency
 
+By default, Logstash uses <<memory-queue,in-memory bounded queues>> between pipeline stages (inputs → pipeline workers) to buffer events. 
+
 As data flows through the event processing pipeline, Logstash may encounter
 situations that prevent it from delivering events to the configured
 output. For example, the data might contain unexpected data types, or