How to architect a centralized citizen address repository

[Alex Glaros]

This is just a theoretical beginner's question, nothing specific in mind.

How would a state-wide (or small country) centralized citizen address bank be architected?

Theoretical purpose. So that DMV, voting, state tax agencies, professional licensing agencies do not have to redundantly create and update separate records for the same citizen.

Aside from details such as different agency update policies, I assume (I don't know much about APIs) an API returning large files (10 million records) of data doesn't work (I.e., requesting agency sends a query). So if the tax agency wanted to send a paper letter to each taxpayer, instead of getting a file of state taxpayer records from the API, they would

1. Keep their own version of all addresses on their mainframe

2. Update their version solely from the centralized table only when updates to the centralized table occur.

Is that how it would work?

thanks

Alex Glaros

[Alex Glaros]

Okay, just spoke with a friend. He said there are two ways.

1. Have a centralized service bureau actually doing the work for agencies such as mailing the paper letters or sending emails on behalf of the various agencies

or

2. Configure the API to send a zipped up raw data table to an agency

He said theoretically it is possible for an API can send millions of records, for example, Los Angeles county requests addresses for each of its citizens.