Data replication conflict detection and resolution for a multi-tenant identity cloud service
Embodiments include a multi-tenant cloud system with a first data center and a second remote data center. The first data center authenticates a first client and stores resources that correspond to the first client, and is in communication with the second data center. The second data center authenticates the first client and replicates the resources. The first data center receives a write request for the first client, writes the write request and generates change event messages in a first order. The first data center pushes the change event messages to the second data center via REST API calls. In response to receiving the change event messages, the second data center is configured to write the change event messages in the first order to its local database.
1. A method of operating a multi-tenant cloud system, the method comprising:
at a first data center, authenticating a first client and storing resources that correspond to the first client in a first data store, the first data center in communication with a second data center that is configured to authenticate the first client and replicate the resources in a second data store;
the first data center receiving a write request for the first client for one of the resources, writing the write request in the first data store, and generating change events, the change events generated as a result of the writing the write request in the first data store;
queuing the change events in a first shard of a first sharded queue at the first data center in a first order, the first sharded queue comprising a single logical queue that is divided into multiple physical queues through system partitioning, the first shard determined based on a computed hash; and
the first data center pushing the change events as change event messages to the second data center via REST API calls;
wherein, in response to receiving the change event messages, the second data center is configured to queue the change events in a second shard of a second sharded queue at the second data center, the second sharded queue in the second data center corresponding to the first sharded queue in the first data center and the second shard corresponding to the first shard, and write the change events in the second data store in a second order comprising a dequeuing order from the second sharded queue.
2. The method of claim 1 . wherein the change event messages comprise JavaScript Object Notation (JSON) messages.
3. The method of claim 1 , wherein the first data center comprises a plurality of sharded queues and the second data center comprises a plurality of sharded queues.
4. The method of claim 1 , wherein the first sharded queue comprises Java Messaging Service (JMS) sharded queues.
5. The method of claim 1 , the second data center configured with an apply handler at the second data center, wherein the apply handler resolves a conflict at the second data center when a replicated resource already exists in response to a create operation by ignoring the change event messages or fetching the one of the resources from the first data center.
6. The method of claim 5 , wherein the apply handler resolves a conflict at the second data center when the replicated resource does not exist in response to an update operation by fetching the one of the resources from the first data center.
7. The method of claim 1 , the first data center comprising a plurality of tenants each having a corresponding partition, further comprising computing the hash that corresponds to a corresponding partition of the first client.
8. A non-transitory computer-readable medium storing instructions which, when executed by at least one of a plurality of processors, cause the processor to operate a multi-tenant cloud system, the operating comprising:
at a first data center, authenticating a first client and storing resources that correspond to the first client in a first data store, the first data center in communication with a second data center that is configured to authenticate the first client and replicate the resources in a second data store;
the first data center receiving a write request for the first client for one of the resources, writing the write request in the first data store, and generating change events, the change events generated as a result of the writing the write request in the first data store;
queuing the change events in a first shard of a first sharded queue at the first data center in a first order, the first sharded queue comprising a single logical queue that is divided into multiple physical queues through system partitioning, the first shard determined based on a computed hash; and
the first data center pushing the change events as change event messages to the second data center via REST API calls;
wherein, in response to receiving the change event messages, the second data center is configured to queue the change events in a second shard of a second sharded queue at the second data center, the second sharded queue in the second data center corresponding to the first sharded queue in the first data center and the second shard corresponding to the first shard, and write the change events in the second data store in a second order comprising a dequeuing order from the second sharded queue.
9. The non--transitory computer-readable medium of claim 8 , wherein the change event messages comprise JavaScript Object Notation (JSON) messages.
10. The non-transitory computer-readable medium of claim 8 , wherein the first data center comprises a plurality of sharded queues and the second data center comprises a plurality of sharded queues.
11. The non-transitory computer-readable medium of 8 , wherein the first sharded queue comprises Java Messaging Service (JMS) sharded queues.
12. The non-transitory computer-readable medium of claim 8 , the second data center configured with an apply handler at the second data center, wherein the apply handler resolves a conflict at the second data center when a replicated resource already exists in response to a create operation by ignoring the change event messages or fetching the one of the resources from the first data center.
13. The non-transitory computer-readable medium of claim 12 , wherein the apply handler resolves a conflict at the second data center when the replicated resource does not exist in response to an update operation by fetching the one of the resources from the first data center.
14. The non--transitory computer-readable medium of claim 8 , the first data center comprising a plurality of tenants each having a corresponding partition, further comprising computing the hash that corresponds to a corresponding partition of the first client.
15. A multi-tenant cloud system data center comprising:
one or more processors that execute instructions to implement an admin service and a replication service;
the admin service is configured to authenticate a first client and store resources that correspond to the first client in a first data store, the data center in communication with a second data center that is configured to authenticate the first client and replicate the resources;
the first data store coupled to the admin service;
wherein the admin service is configured to receive a write request for the first client for one of the resources, write the write request in the first data store and generate change events, the change events generated as a result of the writing the write request in the first data store, and queuing the change c vents in a first shard of a first sharded queue at the first data center in a first order, the first sharded queue comprising a single logical queue that is divided into multiple physical queues through system partitioning, the first shard determined based on a computed hash; and
the replication service is configured to push the change events as change event messages to the second data center via REST API calls;
wherein, in response to receiving the change event messages, the second data center is configured to queue the change events in a second shard of a second sharded queue at the second data center, the second sharded queue in the second data center corresponding to the first sharded queue in the first data center and the second shard corresponding to the first shard, and write the change events in the second data store in a second order comprising a dequeuing order from the second sharded queue.
16. The multi-tenant cloud system data center of claim 15 , wherein the change event messages comprise JavaScript Object Notation (JSON) messages.
17. The multi-tenant cloud system data center of claim 15 , wherein the first data center comprises a plurality of sharded queues and the second data center comprises a plurality of sharded queues.
18. The multi-tenant cloud system data center of claim 15 , wherein the first sharded queue comprises Java Messaging Service (JMS) sharded queues.
19. The multi-tenant cloud system data center of claim 15 , the second data center configured with an apply handler at the second data center, wherein the apply handler resolves a conflict at the second data center when a replicated resource already exists in response to a create operation by ignoring the change event messages or fetching the one of the resources from the data center.
20. The multi-tenant cloud system data center of claim 19 , wherein the apply handler resolves a conflict at the second data center when the replicated resource does not exist in response to an update operation by fetching the one of the resources from the data center.