title: Multiple unary rpc calls vs long-running bidirectional streaming in grpc?
body: <p>I have a use case where many clients need to keep sending a lot of metrics to the server (almost perpetually). The server needs to store these events, and process them later. I don't expect any kind of response from the server for these events.<br>
  I'm thinking of using grpc for this. Initially, I thought client-side streaming would do (<a href="https://github.com/envoyproxy/envoy/blob/master/api/envoy/service/metrics/v2/metrics_service.proto#L19" rel="noreferrer">like how envoy does</a>), but the issue is that client side streaming cannot ensure reliable delivery at application level (i.e. if the stream closed in between, how many messages that were sent were actually processed by the server) and I can't afford this.<br>
  My thought process is, I should either go with bidi streaming, with acks in the server stream, or multiple unary rpc calls (perhaps with some batching of the events in a repeated field for performance).<br>
  Which of these would be better?</p>