Dead issue but I would like to resurrect it because this wasn't answered at all.
Simple use case which can easily illustrate the problem: Two different services OrderService (with CreateOrder method) and AuditService (with Audit method). You want to create the order and, in case everything succeeded, log an audit entry. If you log an entry beforehand you could end with an audit log which never happened because the create order task failed. If you (try to) log an entry afterwards, the audit task could fail and end not logging something that happened which fails its sole purpose of having an audit log at all. What do you guys at Google do? * Compensate? * Nothing more than live with it? * In this concrete case having a custom audit log per service and the CDC (Change Data Capture) and replicate to the central service? @Jiri what did you end up doing? Thanks, On Wednesday, September 9, 2015 at 7:47:51 PM UTC+2, Jorge Canizales wrote: > > For Google's JSON/REST APIs we use ETag headers (optimistic concurrency) > to do these things. That's something easy to implement on top of gRPC, > using the request and response metadata to send the equivalent headers. > > On Wednesday, August 5, 2015 at 1:45:53 AM UTC-7, Jiri Jetmar wrote: >> >> Hi guys, >> >> we are (re-) designing a new RPC-based approach for our backoffice >> services and we are considering the usage of gRPC. Currently we are using a >> REST method to call our services, but we realize with time to design a nice >> REST API is a really hard job and when we look to our internal APIs it >> looks more RPC then REST. Therefore the shift to pure RPC is valid >> alternative. I;m not talking here about public APIs - they will continue to >> be REST-based.. >> >> Now, when there are a number of microservices that are/can be distributed >> one has to compensate issues during commands (write interactions, aka HTTP >> POST, PUT, DELETE). Currently we are using the TCC (try-confirm-cancel) >> pattern. >> >> I'm curious how you guys at Google are solving it ? How you are solving >> the issue with distributed transaction on top of the RPC services ? Are you >> doing to solve it on a more technical level (e.g. a kind of transactional >> monitor), or are you considering it more on a functional/application level >> where the calling client has to compensate failed commands to a service ? >> >> Are the any plans to propose something for gRPC.io ? >> >> Thank you. >> >> Cheers, >> Jiri >> > -- You received this message because you are subscribed to the Google Groups "grpc.io" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/grpc-io. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/c727145c-b8a8-44f3-b857-416b4491362b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
