How would one achieve something similar to database transactions.
Bene, potresti utilizzare le transazioni distribuite, ma non vuoi . E, più probabilmente che no, non è necessario.
What if these services don't expose APIs to rollback a transaction, what would be the solution?
Bene, in realtà è grandioso, quindi non ti sporcherai con le transazioni distribuite. Il modo moderno di gestire cose del genere è utilizzare il concetto di consistenza finale . Significa che il tuo processo aziendale è suddiviso in diversi passaggi, ognuno dei quali viene elaborato ACID-ly. Pertanto, il risultato complessivo non è coerente immediatamente, ma alla fine è coerente, quando vengono elaborati tutti i passaggi.
Di solito è fatto con sagas . Saga è un approccio per ottenere un accordo distribuito di un processo aziendale, e allo stesso tempo è un modo per gestire i fallimenti (c'è un ottimo esempio in un post a cui mi sono collegato). Non si tratta di un certo modo in cui possono essere implementati. Potrebbero avere un sincrono controllo centralizzato, controllo centralizzato asincrono o a distributed .
In the case where rollback is not available, what would be the correct order to consume each service?
Dipende totalmente dal tuo dominio. Quando non ha importanza dal punto di vista del business, il buon senso è iniziare con un'azione più facile da eseguire, in modo che l'azione più rischiosa, che richiede il rollback più complesso, sia l'ultima.
Ecco un esempio nell'e-commerce , usando l'approccio alla saga sopra menzionato.