Clarification: 2.3.3 "entirety or it is rolled back "

[ajayojha]

Verify that transactions are being used at the business logic level such that
either a business logic operation succeeds in its entirety or it is rolled back to
the previous correct state.

I have no concern on security goal, but the wording is biased toward monolithic ACID. How this requirement is verifiable for event-driven systems where Sagas or eventual consistency is used?

[elarlang]

It must be ensured that the state of related operations is handled. Data and business operation integrity can not fail just because "I use an event-driven system".

How it is verifiable - it really depends on the case, every business logic step is different, but the main principle is the same - the entire set of actions must succeed to not have an integrity failure.

(If this answer will cause new questions, I'll leave it to someone else in advance. But I think that this issue can be closed.)

[jmanico]

I agree with Elar here. I think the requirement encapsulates both of these concerns already.

[ajayojha]

I agree that data and business operation integrity cannot be sacrificed “because I use an event-driven system.” My concern is not with the security objective; it is with how the current wording expresses it.

The current wording ("transactions... rolled back to the previous correct state") reads as monolithic-biased. The requirement wording is not perfect for event driven, sagas, or outbox pattern. These patterns are highly used in microservice based application. I am assuming that the leaders may have not considered the use cases of mentioned pattern while drafting the requirement.

the main principle is the same

The is vague or general statement. I don’t think it is accurate for the patterns mentioned above as currently worded in the requirement. In Saga-style flows, for example, the “entire set of actions” does not all succeed, and you do not revert to a previous state, you have to start a new consistent state.

I think the requirement encapsulates both of these concerns already.

I strongly disagree. If you can explain how the current requirement text covers event-driven / Saga / outbox use cases from a verification perspective, that would be very helpful. If you would like, I can also provide more detailed examples to explain why I think the current wording does not encapsulate these concerns.

As the two leaders are agree that there is no problem in the requirement wording. I am OK if leaders wants to close this ticket, as I just don't want to spend more time on a topic where the concern is not being fully engaged with, and where the response is effectively “I don’t see a problem” rather than explaining why my reasoning is flawed with concrete examples/references.