Feature/initial cut

Using mini-batches most of the time is a trade-off between processing latency and throughput. You pay less overhead for transactions to reach higher throughput. At the same time your event is processed only when the whole batch is processed which usually means higher latency.

When doing batching you also need to be most careful about two things:
* running out of memory
* increased chance for conflicts

Since you process data in batches, you keep the whole batch and intermediate data in memory, which grows if you increase the batch size.

When you consume data with multiple flowlet instances which update same values in datasets there is a chance for a conflict. The framework resolves them automatically, but in the end, you pay a price for the overhead caused by retry. When batch size grows, the chance for a conflict increases as more rows are modified by overlapping transactions. In this case it is important to correctly partition data between flowlet instances to reduce the chance of the conflict or to avoid it completely.

The default partitioning strategy is round-robin, which basically means that data is partitioned randomly and different batches processed in parallel may have same values and may result in updating same cells in a dataset. Using hash-partitioning will help to resolve this. Let's take a look at the data flow of our application to see how we can employ hash-partitioning strategy to avoid conflicts. 

<then your text with nice examples, etc. - the one that you have below>