Skip to main content

Question Transactions on Domain Level

Context​

Microservices are in use or are planned to be adopted. There is an apparent need to implement transactions across microservices in order to guarantee strong consistency.

Problem​

  • Distributed transactions are notoriously difficult and error-prone to implement.
  • Distributed transactions introduce coupling between microservices since all involved microservices need to be available for the transaction.

Solution​

Question the need for a transaction and its consistency needs on the domain level.

Many real-world processes are not as transactional as software engineers think. For example, in order processes in webshops, it often doesn't matter if the order is processed immediately or within a few hours. Another example is bank transfers. The real transfer happens overnight because it is very costly, at "payment" time only reservations are used with less strong consistency guarantees. There is a chance that two concurring reservations go past the limit of the bank account - meaning for the bank a potential loss of money. However, the chances are so small and the costs for a better-designed mechanism so high that they accept this risk.

If eventual consistency is acceptable:

  • use workfows or no-ACID transactions in combination with compensation workflows to realize the use-case, or
  • use data replication to make data available to other microservices with eventual consistency guarantees.

If there is a need from domain perspective for strong consistency:

Maturity​

Proposed, requires evaluation.

Sources of Evidence​

Interview B:

  • Trick: question the domain functionality => is the reality transactional?
    • not as transactional as we might think!
    • Example: opening a bank account
      • fill out many forms
      • mandatory fields: without cannot go further
        • example: birthdate of wife
        • can't open bank account
      • in reality bank account would have been opened, but without wife having access
    • DDD, distributness, etc. forces us to think about domain alternatives
  • replication => latency until all others know about update
    • for a short period: eventual consistency => not transactional
    • figure out if this is relevant from domain perspective
      • click paths at user => usually doesn't even notice => not relevant
    • need to detect when replication didn't work / took to long
      • dead letter queue + timeout
      • run a compensation
      • or let other services know they have out-of-date data

Interview C:

  • otto.de
    • where in system is eventual consistency not okay?
    • customer gets delivery in 2-3 days, even with prime next day
      • system has to be running really bad if order processing does not happen within 8-10 hours
    • change of catalogue
      • what if synced over night? No problem!
    • bank transfer
      • I'm not interested in it happening consistently right now, but within 2-3 days
      • 2-step mode: reserve money
        • bank hopes not 2 reservations too shortly after another
        • usually cannot use my card that fast twice to go over my limit
        • the actual processing happens over night because it is expensive (HW security modules, transactions, 2-phase commit over multiple institutions, ...)
        • bank: how are the odds something goes wrong? very low!
          • how much would it cost to build system better? much more!
          • => accept the risk and that's it!
  • domain specific decision how to deal with eventual consistency, not a technical one!
    • topic eventual consistency not really complex
    • domain (expert) specifies the problem and the different solutions
      • not IT people most of the time
      • IT people have to understand what is going on in the domain! => link to BizDevOps

Interview E:

  • Context: effects of eventual consistency to frontends
  • no big deal: users don't expect immediate effects
  • if this is not the case: communicate it
    • "Thanks for your input, the changes will be available in the other modules in a few minutes" or "We received your input and are processing it"
  • ACID transactions are acquired like DRY - we got good grades on it in our studies
    • But often there is no reason for transactions
    • cites someone else: there is no functional requirement for ACID because it doesn't exist in the Workload
      • not even in the finance sector that is often taken as example
      • a little exaggerated, but it summarizes the point well