Software at APNIC is undergoing some architectural changes, aiming to produce systems which are robust, reliable, and responsive. This article will explain one technique we’re using to achieve responsiveness and reliability: eventual consistency.
The technique is simple: accept that systems don’t have perfect reliability or perfect reachability, and adapt your approach to be responsive given imperfect communication as a precondition.
As a concrete example, the membership application form used to behave according to stronger expectations of consistency. Once an applicant had clicked “submit” on the final page of the form, the server would immediately work to synchronise internal systems such that they all agreed there was a new account. Once those systems had been initialised, the server would respond to the applicant informing them their application had been received successfully.
The membership application form now behaves with an expectation of eventual consistency. When an applicant clicks “submit”, the server writes the form details into a database, and then responds to the applicant informing them their application has been received successfully. Subsequent processes observe the application’s arrival, and synchronise internal systems.
The second model has a number of benefits. First, submitting a membership application is significantly faster now. A database write is unlikely to fail, and its failures are generally predictable and avoidable: disk full, CPU or memory contention, and the like, so the membership application process is very reliable. Second, none of the things that could go wrong when synchronising internal systems are caused by the applicant, and there is nothing they can do to fix them. Instead, these faults are raised for Secretariat attention, corrected, and the membership application process continues.
Consistency, used in this way, doesn’t strictly refer to consistency models. It refers to systems being consistent with expectations of behaviour, so perhaps it would be more properly called “eventual correctness.” It’s a principle we use to provide greater reliability and resilience at the user-facing edge of our services, without going to the significant expense of ensuring very high availability of all the internal service delivery components which are composed together to effect APNIC’s business processes.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.