Multiple Users from multiple Parties may be submitting registry transactions simultaneously. Each transaction takes some time to process (varying by on transaction type and system load), so we cannot guarantee that every transaction will return a complete response within a specific time window. At the same time, we want to be sure that one Party, who is submitting individual transactional records, is not penalized because another Party has submitted a large catalog data set.
The Production registry is supported by two separate registry services:
- Primary – the authoritative registry where all write transactions are applied
- Mirror – a synchronized copy of the Primary that processes read-only transactions
All un-authenticated Web UI and ID resolution requests are directed to the Mirror to lighten the service load on the Primary.
Users are encouraged to send large queries to the Mirror rather than to the Primary, reserving the Primary for write transactions and incidental reads.
The registry has two separate thread pools that it uses to send transactions to the de-duplication system. They are divided between synchronous and asynchronous transactions.
- Synchronous – transactions are processed FIFO (first in, first out) while they wait on an available de-duplication thread. Since the de-duplication process can take different amounts of time depending on the nature of the record submitted and the likely duplicates encountered, the results are not returned to the user in strict FIFO order.
- Asynchronous – transactions are processed in a round-robin order. A pending transaction from each queued Party is processed in turn, preventing a large batch from blocking later submissions.
 And to use large page sizes – 10000 instead of the more common 200 – to reduce the transaction and communications overhead associated with large data sets. The net result is a significant improvement in query response times.