cancel
Showing results for 
Search instead for 
Did you mean: 

Micro services for transaction systems OLTP

0 Kudos

If we implement micro services , or restful programming where we distribute actions to multiple urls ,

how do we leverage this for

1.concurrent transactions like posting a sales order for a specific PO , can we implement parallel processing between multiple servers


2. If we want to delink database to each app server to achieve non monolithic architecture how do we ensure data is consistent , partition db and distribute number ranges ?

Accepted Solutions (0)

Answers (1)

Answers (1)

Ivan-Mirisola
Product and Topic Expert
Product and Topic Expert
0 Kudos

Hi chavadiyil.joseph,

1. Concurrent transactions

When dealing with a transaction in the context of a stateless service like REST or OData, you have to deal with key processing yourself. Thus, your REST service application will have to rely on the state at the back-end level - probably your database will have to reserving a key like PO number from a number range before commit any information at the back-end. BTW: This is also true in the context of monolithic applications. Concurrent transaction processing is handled by the database. However, when you implement it the correct way, there is a low chance of having concurrency issues. We want to avoid issues like selling the same item twice. That's why you can only commit a transaction when you have checked for product availability once more at the final stage. There is also the possibility to avoid most situations by making a reservation on the database (lock) while you are still working on a particular transaction. Then either unlock or commit the reserved product only when the transaction is no longer valid or checked-out.

On the 12-factor principals, concurrency means you can have more then one instance of the same microservice - but they all have to be processing a distinct transaction. Meaning: you your OData service needs to be able to handle any given transaction - regardless of which process has started it.

In OData you can make use of the ETag to determine if a particular call is producing a different result-set which might mean you need to re-check something at the database. This can be very usefull to implement optimistic locking in OData. Basically the service will use the value of an ETag to identify a transaction so you can deal with it later at any other service instance. Please have a look at:

https://www.odata.org/documentation/odata-version-2-0/operations --> Concurrency Control and ETags

https://blogs.sap.com/2019/04/25/new-versions-of-sap-s4hana-cloud-sdk-2.15.0-for-java-and-1.1.0-for-... --> Optimistic concurrency control

https://blogs.sap.com/2017/06/30/optimistic-locking-etag-in-sapui5/

2. Every microservice has to connect to the same database. All microservices are stateless - thus, the transaction data and state should never be kept at the microservice level. Some implementations will have a microservice send write requests to another microservice via a queue (like RabbitMQ). Another microservice listens to the same queue and retrieves each operation to handle them sequentially at the database (since most checks have already been validated previously, the operation can always be commited - as long as there is no other process dealing with the same entities). Other implementations will have all instances of microservices writing to the database at any given point in time. It is up to the database to be able to handle each transaction properly.

If you implement your service to handle ETags, then your database will be able to retrieve and manipulate any pending transaction independent of which microservice instance is handling the request.

It is up to you to figure the best approach. Keep in mind that depending on the complexity of the application, managing writes (inserts and updates) via a queue will pose an overhead in development, but might be a better option - depending on the database you are planning to use.

3. Worth mentioning

You didn't mention in your questions, but there is also the possibility that the microservice looses connection to its database. In such case, you might want to investigate the usage of Netflix's Hystrix libraries to provide a circuit breaker. The idea is to avoid UI errors related to database connection loss. While the database connection is not available, your circuit breaker could instruct the microservice to store data on a flat-file in another persistence storage service. Once it is back on-line it can read the flat-file and push the data to your database. In that case, it best to prepare the microservice to handle the data import in sequence by the first one that detects the database is back on-line - others will wait until data import is finished. The circuit breaker could also read data from a flat file. So you could still have your UI working by either selling pre-arrenged contracts that are independent of stock availability or present a more comprehensible error message to the UI (shopping cart processing is not available at this time - please try again latter. Or something along those lines).

Hope this helps!

Best regards,
Ivan

0 Kudos

Thanks Ivan for the clear responses pointwise.