q: when using SpiceDB/authzed, permissions data li...
# spicedb
f
q: when using SpiceDB/authzed, permissions data lives in the ReBAC db. What's the recommended approach to handling transactionality between the application DB updates and writing new relations to SpiceDB?
d
I don't work for authzed/spiceDB, so I don't know if there's anything specific possible What you describe is a common fallacy of real distributed systems (aka "microservices"). You may want to look at the "transactional outbox pattern", and/or "saga pattern", and perhaps into "change data capture" (CDC). See e.g. https://microservices.io/patterns/data/transactional-outbox.html https://microservices.io/patterns/data/saga.html https://medium.com/event-driven-utopia/sending-reliable-event-notifications-with-transactional-outbox-pattern-7a7c69158d1b I darkly remember a blog post mentioning these, but couldn't find it as of now, sry. Hope that helps a bit 🙂
v
in I always link to Red Hat's patterns for distributed transactions, I think it covers most patterns out there: https://developers.redhat.com/articles/2021/09/21/distributed-transaction-patterns-microservices-compared
d
as i am working for that org, i try not to advertize too much. but yes, that's a great page 😉
v
heh 💯
e
v
that does not work. Nothing prevents a hardware failure to leave things in an inconsistent state. Real distributed transactions can be achieved via X/OpenXA https://es.wikipedia.org/wiki/X/Open_XA, but is known to be difficult to scale (not that I ever done it myself, but what I gather from reading)
e
yeah, we have many strategies, but none of them will be like a transaction in a monolith database app. you need to analyze the criticality of you system to decide the approach ...
f
I can't imagine many customers want to invest in running a XA manager etc. Is anyone actually doing this? I'm guessing the most common strategy is "read/write relations before opening txns on app DB, if failure occurs between then, accept the fact you may have stale relations and design around that?"
v
@fierro9418 I didn't intend to suggest that was the recommended way to go, but rather that 2PC cannot be achieved with the naive approach described in the aforementioned docs, and that XA transactions are a way to achieve it. As Erick also mentioned above, the solution largely depends on your architecture. We have some customers that already have Kafka deployed, so they've gone with the Transaction Log Tailing / CDC approach. You'd need to decide if data integrity issues are acceptable in your setup.
f
makes sense, thanks!