Resource locking and business logic

Question

Consider the following situation: There is an update request on Entity A, to create sub-entity A.B. there might be many B's on A, each B has unique email address. The entity A is a shared entity, and the same request can happen in multiple servers in parallel (scalable micro-service).

In order to create A.B we have to verify that B does not already exist as sub entity on A (according to B's email address).

The service which handles this update request should lock A(by it's unique id) in order to make the update safe.

My questions are more conceptual than technical:

1. Does locking the resource A in this case is part of the business logic of this update task?

2. Would you consider putting the resource lock in a separate middleware than the one which handles the verify and update procedure? (the other option is to treat the lock as part of the business logic and put it directly in the middleware responsible for the business logic.)

Answer 1

The technical implementation of the chosen solution to contention problems is obviously not business logic, but choosing the right solution requires business knowledge.

What I mean by this is that you must understand how the business works in order to determine the right approach to protect the integrity of the data in concurrency scenarios. How often concurrency conflicts will occur? Can conflicts be resolved automatically? What should be conflicting? Not only that, but the business may very well accept eventual consistency over strong consistency.

In short, the mechanisms put in place to protect the data integrity in concurrency scenarios shouldn't be part of the domain. These would probably go either in the application service layer or in the infrastructure layer, but the business experts must be involved in the discussions regarding how concurrency conflicts should be resolved and how these affects the business.

Answer 2

Locking is not a business related issue (unless your business is building distributed databases), and so should never be considered part of the business logic.

Further, you should not be implementing distributed locking yourself, but should be relying on a packaged solution, that is preferably part of your data persistence solution.

Here's an article on how to do this with Redis discussing an algorithm called Redlock. Here's a blog post linking to articles about building concensus in Cassandra. And, here's a link about concurrency in Mongo. As you'll see from these articles, distributed locking is a big and complex issue that you probably don't want to tackle yourself.