...
- Participants can be replicated, each participant can have an arbitrary number of replicas
- Composition definitions, instances, element instances and all their data including properties is identical in all participant replicas
- When anything is changed in one replica, the change is propagated to all the replicas of a participant
- An operation on a composition element can be sent to any replica of a participant, which means that for a given element, the deploy could be on replica 1, the update could be on replica 2 and the delete could be on replica 3, as one would expect in any HA solution
- A single REST operation called on ACM-R will select a participant replica (probably using round robin initially but we could support other algorithms in the future), and use that replica for that operation.
- The ACM runtime will be made HA (more than one replica of ACM-R will be supported), it will run on a HA postgres.
- The implementation of change propagation replication mechanism used between ACM-R and participants is transparent to participant API users
- Replicas are "eventually consistent", with consistency typically occurring in 100s of milliseconds
...
- We will preserve Participant Design backward compatibility, there is no change to the participant intermediary interface for participant implementations
- Participant version backward compatibility will not be preserved because we need to pass replica information in the registration and operational messages, all participants will have to be upgraded to the new version.
- ACM-R introduces a new REST API for replica managementThe REST API that returns participant information will be updated to include replica information
- ACM-R is made HA so that it itself can scale
- We can use Kafka load balancing on the participants and get the load balancing functionality for nothing
- A new Kafka topic is used for synchronization
...