hi folks, since i am currently working on a project in the microservice world, i am interested in how a12 can best be used in this world. currently, i have a question about the use of the bap server. let’s assume i would run several services in parallel in a k8s cluster, where each service would be a self-contained a12 application. what would be the best way to set up the bap server in the cluster? would one use one server (possibly with several replicas) or could one possibly run several bap servers in parallel in the cluster. i ask because in the microservice world it is not uncommon to use the Database per Service pattern, i.e. all data of one service is hard separated from the data of other services. in the relational world this can be realized for example by separate DB schemas within one DB server but also by running several independent DB servers. In the A12 world, how would it be best to ensure that the models and documents of one service are cleanly separated from the models and documents of another service?
We are trying to come up with a set of rules and recommendations on how to separate the concerns that you are mentioning in your question here: <INTERNAL_LINK> These questions do not have one-fit-all solutions but there are multifaceted problems that we are addressing in a holistic way. We want to provide as much flexibility as possible to the client projects and information about possibilities and the consequences of those designs. It is also possible to combine different patterns for different use-cases.
Database per service pattern is great for separation of concerns but transaction handling will be difficult for the distributed databases. We have invested a lot of effort in transaction scoping and behavior which will not work well if all your subsystems are in different pods.
The link I sent you is still a work in progress so consider it a sneak preview of the new concepts that we are preparing. I hope the results will help client projects to make better informed decisions about the design of the system.
Hi Tomas, i’ve been wondering about the handling of distributed TAs for a long time now. the good thing is, you hardly ever need them in the real world 
distributed transactions are a very good construct if you want to manage multiple transactional resources within one application. for example, if you read a message from a message queue and want to make sure that its content was actually stored in the DB before the message was deleted from the queue. however, when it comes to handling the interactions between different applications, distributed TAs are usually not very good. but that’s a whole other discussion
We have spent a lot of time thinking about two-phase commits and how to handle synchronization between DB, Solr, filesystem (and potentially other systems that we can integrate). Our main challenge that we faced was with different transactional scopes between DB and Solr. Solr uses transaction logs where all uncommited changes (regardless of origin) are stored and then those changes are either flushed or rolledback (at some point). This is very different to the true DB transactional scopes. Rollback of Solr transaction could also revert the changes that have been created by different DB transactions originating from other requests.
Our JSON-RPC endpoint has a request scope transaction. During this transaction we are collecting the changes that have been made to the documents. If there is a commit, we are sure that the changes have been persisted in the DB and in the index (we can discard the changes we collected). But in case of exceptions, we can be sure that the database is consistent but the index has been updated with the data that has been rolledback. Therefore we must use the collected document changes and sent “rollback” request to the search service.
With this approach, we only make sure that the collected operations have inverted counterparts (which works fine if we update by copy), that we are not missing any changes and that we do not have leaks between different transactions.
In our sample module, we are experimenting with different pesistence location of documents which means different transaction handling and rollback mechanisms.
Needless to say this topic is quite big and there are reasons to not be transactional but we are trying to be as close to transactional as possible