Keep lookup data consistent ​

Use a table for lookup data that must be queried and updated through Coordinator DB. There is no separately refreshed dictionary service to synchronize across requests.

CREATE TABLE product_labels(
    product_id INTEGER PRIMARY KEY,
    label TEXT NOT NULL
);
INSERT INTO product_labels VALUES (1, 'Notebook'), (2, 'Pen');

SELECT product_id, label
FROM product_labels
WHERE product_id = 1;

The primary key prevents several labels from competing for the same product identifier. If lookup changes must agree with related table changes, put them in one transaction and commit only after all statements succeed. A failure can then be rolled back as a unit instead of leaving one table partially updated.

For a larger lookup replacement, load and validate the proposed data first. Check duplicate keys, missing required values and referential assumptions before replacing the reader-visible data. The application must choose the replacement procedure; no background refresh interval makes independently submitted statements atomic.

HTTP transaction steps belong in one request, while a native connection can retain the transaction across submissions. Multiple clients should connect to one server rather than opening the same file from separate processes.

See constraints, transactions and deployment modes.