Reactive architecture

@TomCS @richardcs @jacobcs Please review and provide feedback.  I believe Tom and Richard has already reviewed these documents but just in case I would like a final review.  These articles are intended to define how we should apply microservices at CoSo assuming we get approval.
When we talk about a single purpose microservice having a single endpoint, I often find the single endpoint piece not practical because there is a coupling of input information (data) with context (metadata) and because the microservice keeps its own data storage, it must track such context. This often leads to the desire to sometimes fetch portions of this context, resulting in more read endpoints. 

A slight alternative that makes more sense to me is advocate the ingest of only a single type of data (or message), for example a list of meetings. So a microservice would receive and process a single packet type (perform CUD operations) from n different sources and then make available the practical endpoints for asking questions (R) about the processed data. 

The above might not be clear, but the short version is I think we might need more exemplars of real-world single-purpose microservices to help demonstrate that it is feasible and makes sense without creating entangled dependencies.