Data consistency requires distributed services to maintain compatible views of application state. Separate stores such as PostgreSQL and Redis do not guarantee agreement, so consistency must be checked through service APIs. section 2.4 section 2.4.4
Eventual consistency accepts that services may disagree temporarily while requiring the system to converge. A periodic check can compare accepted talks in the Agenda service with approved proposals in the Call for Proposals service. section 2.4.4
A practical consistency check can:
- Run as a Kubernetes CronJob at an interval chosen according to the importance of correcting inconsistencies. section 2.4.4
- Query public APIs rather than reaching directly into another service’s data store. section 2.4.4
- Compare published sessions with approved proposals and notify conference organizers when a mismatch appears. section 2.4.4
Conference consistency check
At a scheduled run, the checker retrieves accepted talks from the Agenda service, compares them with the Call for Proposals service’s approved list, and uses the Notifications service to email organizers about discrepancies. A related check can verify that approval and rejection emails were sent. section 2.4.4
Figure 2.27 Consistency checks can run as CronJobs. We can execute checks against the application services on fixed intervals to make sure that the state is consistent. For example: (1) every day at midnight we query the Agenda Service (2) to verify that the published sessions are approved in the (3) Call For Proposals Service and a corresponding notification has been sent by the (4) Notifications Service.
The workflow diagram connects the scheduled job, queried service APIs, comparison step, and notification path. section 2.4.4
