More review feedback applied.

docs/ocis/adr/0015-events.md

@@ -19,7 +19,7 @@ To be able to implement simple, flexible and independent inter service communica
 
 ###  Example: Email Notification
 
-A simple example is the notification feature for oCIS: Users should receive an email when another user shares a file with them. The information, that the file was shared should go out as an event from the share manager, carrying the information which file was shared to which receiver. A potential notification service that sends out the email listens to these kind of events and sends the email out once on every received event of that specific type.
+A simple example is the notification feature for oCIS: Users should receive an email when another user shares a file with them. The information, that the file was shared should go out as an event from a storage provider or share manager, carrying the information which file was shared to which receiver. A potential notification service that sends out the email listens to these kind of events and sends the email out once on every received event of that specific type.
 
 ## Decision Drivers
 
@@ -42,7 +42,7 @@ Reva will get a messaging service that is available to all services within oCIS
 
 All oCIS- and Reva-services can connect to the messaging bus and send so called events. The sender gets an immediate return if handing the event to the message bus was succesful or not.
 
-The sender can not make any assumptions about when the message is delivered to any receiving service, nor if zero, one or many services are listening to that event.
+The sender can not make any assumptions when the message is delivered to any receiving service. Depending on the QoS model (as proposed as alternatives in this ADR) it might even be not guaranteed that the event is delivered at all. Also, the sender can not know if zero, one or many services are listening to that event.
 
 #### Event Data
 
@@ -60,11 +60,12 @@ Events are sent with "At most once" quality of service. That means, if a receive
 
 The described way of inter service communication with events is not transactional. It is not supposed to be, but only provides a lightweight, loosely coupled way to "inform".
 
-If transactions are required, proper synchronous GRPC API calls are to be used. Another way would be to build asynchronous flows with request- and reply events in an asynchronous way. That is only recommended for special cases.
+If transactions are required, proper synchronous GRPC API calls should be used. Another way would be to build asynchronous flows with request- and reply events as in [saga pattern](https://microservices.io/patterns/data/saga.html). That is only recommended for special cases.
 
 #### Pros
 - Simple setup
 - Flexible way of connecting services
+- Stateless event queue
 - "State of the art" pattern in microservices architectures
 
 #### Cons
@@ -78,8 +79,9 @@ Exactly as described above, but with a higher service level quality.
 
 #### Pros
 - Better service level: Messages do not get lost.
--
 
+#### Cons
+- Stateful event system with higher cost in terms of compute and storage.
 
 
 ## Decision Outcome