A learned society’s authoritative membership register lives on the local network at its offices, yet the services facing its members must sit on a public server: the problem is replicating the data between two machines that cannot trust the same network. I have been working through this scheme for weeks, applied to the membership management of the SIRM, the Italian Society of Medical Radiology, and these are the technical notes I take from it.

Context and problem

A professional society with thousands of members accumulates separate systems over time: a register application for member records, spreadsheets for accounting, a mail server for email, a few static pages for the website. Each system holds a partial copy of the member’s data and none is authoritative. Reconciling a changed address or a paid subscription means touching three archives by hand.

The constraint that reshapes the design is physical location. The authoritative member record must stay on site — for reasons of control, of responsibility over data handling, and because the office staff work on the local network. The outward-facing services — paying the subscription by card, registering for a training event, society ballots — must instead sit on a server reachable from the Internet, which by definition one does not want exposed inside the office network.

Hence the choice of two nodes rather than one: a server on site with the authoritative database, a server in hosting that keeps a copy of it for the public services alone.

Architecture

The member’s identity data — who they are, their credentials, their membership of sections and study groups — sits in an LDAP directory. LDAP is the right call here because the model is a hierarchy of entries with multi-valued attributes, and because the same directory already authenticates the mail. The schema draws on the standard person classes of RFC 2256, extended with society-specific attributes for membership number, regional section and subscription status. The protocol is LDAPv3 (RFC 2251).

The transactional data — payments, event registrations, congress abstracts — sits instead in MySQL, where referential consistency between tables weighs more than a tree structure.

The web services run on Zope: the Python application server keeps its application objects in ZODB, its object database, and talks to LDAP and MySQL for the structured data. I chose Zope because a society’s logic — a member belongs to a section, which belongs to a committee — models more naturally as a graph of objects than as table rows.

Replication between the two nodes follows the direction of the data:

  • Identity flows from the LDAP on site to an LDAP copy in hosting. The public front-end reads from this copy to authenticate the member and never writes to the authoritative register.
  • Transactions originate in hosting — that is where the member pays and registers — and travel back to the database on site, where the office reconciles them against the register.

The channel between the two nodes is encrypted with SSL. Where the office connectivity is not permanent, transaction replication runs deferred: it queues the writes and drains them on reconnection. Read-only identity tolerates a delay well, because a new member who cannot pay for a few minutes is an annoyance, not lost data.

The critical point

The risk of the whole scheme is the direction of writes. If both nodes could write to the register, a change made on site and one made in hosting against the same member would lead to a conflict that no automatic rule resolves cleanly: which address is the right one, the one typed by the office or the one updated by the member on the portal?

The answer is to remove the symmetry. The register has a single source of truth, the node on site. The hosting node is read-only on identity and write-only on transactions, which the office imports but does not generate. This way there are no two concurrent writes on the same field, and replication becomes a one-way flow for each class of data rather than a bidirectional synchronisation to arbitrate.

MySQL replication helps on this front: in the master-slave model introduced with the 4.0 series, writes go to the master and the slaves apply, in order, what they read from the master’s binary log. The slave accepts no writes that compete with the master. The same principle — one writer per datum — applies to the LDAP branch as well, where the hosting copy is a consumer and never a master.

Implications

Keeping LDAP as the source of identity has an effect beyond membership management: the mail server already in production authenticates mailboxes against the same directory. Mailbox, disk quota, aliases and vacation rules become attributes of the member, not a separate system to keep aligned by hand. When the office suspends a member in arrears, the mail suspension follows from the same status change in the directory.

On the side of obligations, a system that handles events carrying ECM credits — the Continuing Medical Education programme launched by the Italian Ministry of Health in 2002 — must tie each attendance to the member’s record and keep its history, because the training credit has to be certified to the individual professional. Having identity and attendance in the same setup, rather than in disconnected archives, is what makes that certificate verifiable.

Accessibility is not a detail to defer: a portal aimed at a professional category falls under the AIPA guidelines for public-utility sites and under the W3C’s WAI recommendations. Building pages with correct markup from the start costs less than retrofitting them later.

Limits

The scheme holds as long as the direction of writes stays clean. The moment a requirement asks members to edit their own register entry from the portal — not a transaction, but the authoritative datum — the clean separation breaks and an approval path is needed to carry the change back to the on-site node before it takes effect. It is a foreseeable complication, to be designed separately rather than grafted onto replication.

The second limit is operational. Deferred replication over intermittent connectivity moves the problem from availability to the queue: if the office stays offline for long, transactions pile up in hosting and the reconciliation window widens. The queue length must be monitored, not just the state of the two servers, because two nodes both up can still be out of sync.

There remains the dependence on the open-source stack as a whole — Linux, Apache, Python, Zope, MySQL, the LDAP branch — of which this architecture is a product: none of these components is a freely swappable detail here, and the coherence of the set is part of the design.

On this groundwork noze is building an integrated membership management system for the SIRM, where the master-slave replication extends to the Hermes mail server already in hosting through the shared LDAP directory: https://www.noze.it/en/insights/sirm-member-management-system/.

https://www.rfc-editor.org/rfc/rfc2251 https://www.rfc-editor.org/rfc/rfc2256 https://www.sirm.org/ https://www.zope.org/ https://www.mysql.com/ https://www.w3.org/WAI/

Cover image: Black-and-white X-ray of a human hand with a ring on the ring finger; the bones appear bright against a dark background — photo by Wilhelm Conrad Röntgen, public domain — https://commons.wikimedia.org/wiki/File:First_medical_X-ray_by_Wilhelm_R%C3%B6ntgen_of_his_wife_Anna_Bertha_Ludwig%27s_hand_-_18951222.jpg