Start fleshing out content and areas to explore

docs/static/mem-queue.asciidoc

@@ -1,10 +1,51 @@
 [[memory-queue]]
-=== Memory queue
-
-By default, Logstash uses in-memory bounded queues between pipeline stages
-(inputs → pipeline workers) to buffer events. The size of these in-memory
-queues is fixed and not configurable. If Logstash experiences a temporary
-machine failure, the contents of the in-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. 
+=== 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,28 @@
 [[resiliency]]
 == Data resiliency
 
+
+/////
+What happens when the queue is full?
+Input plugins push data into the queue, and filters pull out. If the queue (persistent or memory) is full then the input plugin thread blocks.
+
+See handling backpressure topic. Relocate this info for better visibility? 
+/////
+
+
+/////
+Settings in logstash.yml and pipelines.yml can interract in unintuitive ways
+
+A setting on a pipeline in pipelines.yml takes precedence, falling back to the value in logstash.yml if there is no setting present for the specific pipeline, falling back to the default if there is no value present in logstash.yml
+
+^^ This is true for any setting in both logstash.yml and pipelines.yml, but seems to trip people up in PQs.  Other queues, too? 
+/////
+
+
+//ToDo: Add MQ to discussion (for compare/constrast), even thought it's not really considered a "resiliency feature". Messaging will need to be updated. 
+
+
+
 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