You need a database and logger service that supports XA transactions. Sometimes it is easier to just log in the database under the same transaction.
> On Nov 5, 2018, at 3:16 AM, [email protected] wrote: > > 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. -- 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/9447AC93-D7CB-4F33-ACBB-3CB775E3504F%40earthlink.net. For more options, visit https://groups.google.com/d/optout.
