The Most Important Screen Is A Database Decision

Mostafa Dhouib·9 min read

The Most Important Screen Is A Database Decision

The short answer. Before any design work, decide which system holds the official copy of each piece of data your product touches. That single decision sets three things at once. The compliance posture, because obligations attach to whoever holds the record. The monthly cost, because governed storage with audit trails and retention is priced differently from ordinary storage. And whether a later integration is an addition or a rebuild, because integrating with the holder of record is work and becoming the holder of record afterwards is a migration. Make the decision per datum rather than once for the product. Bundling everything into one posture applies an expensive regime to data that never needed it.

The request is usually for screens. A clinician view, a patient view, an onboarding flow. The screens are the visible product and they are not the first decision, and teams discover that in the second year when a partner asks to integrate.

What "system of record" means operationally

The official copy is the one that wins. If two systems disagree about a value, the system of record is the one that is right by definition, and the other is stale. Three things follow from holding it.

You own the obligations. Retention, audit trail, access control, the ability to produce the data on request, the ability to correct it with a trace, breach handling, and whatever your regime says about export or portability. These attach to whoever holds the record, not to whoever displays it.

You own the corrections. When a value is wrong, the fix happens in the system of record and propagates. A product that displays data it does not own cannot fix it, which is a support reality long before it is a compliance one.

You own the integration surface. Everyone else reads from you. That is leverage and it is also a permanent commitment to an interface.

A product that holds no record of its own is a client. A product that holds some records is a participant. Which one you are is decided by this choice and is extremely expensive to change later.

Decide it per datum, not for the product

The mistake is treating this as one question with one answer. It is one question per category of data, and the answers differ.

Take a connected health product. The data it touches might include clinical observations, device telemetry, a care plan, user preferences, notification history, analytics events, consent records, identity and credentials, support correspondence, and derived scores. Ask of each: which system holds the official copy?

The answers will not match. Clinical observations may belong in an existing clinical system, with your product holding a cached read for display. Device telemetry almost certainly originates with you, because no other system exists to hold it. Consent records may need to live where the governed record lives, because they are evidence. User preferences are yours and nobody else wants them. Identity may belong to an external provider. Derived scores are a layer you compute, and whether they are a source or a derived layer is the question in if you cannot rebuild it, it is a source.

Working through this list produces a table with one row per data category and four columns: which system holds the official copy, which systems hold copies and how stale they may be, which obligations attach, and what the storage and audit cost is. That table is the architecture. Everything else is consequence.

Where the datum originates is the default answer, not the final one. Data created by your device usually has no other candidate holder. Data created in a clinical setting usually has an obvious existing holder, and taking the record away from it is a decision requiring a reason.

The holder should be whoever is obliged to produce it. If an organisation has a duty to produce a record on demand for years, that organisation should hold the official copy rather than depend on a supplier's uptime and continuity.

Where it has to be corrected matters more than where it is read. Follow the correction path. The system where a human fixes a wrong value is almost always the right system of record, regardless of how many places display it.

Why bundling is expensive

The tempting simplification is to put everything in one place under one posture. Usually that means applying the strictest regime to the whole dataset, because mixing governed and ungoverned data in one store means the whole store inherits the governed treatment.

That is where the monthly cost comes from. Governed storage with audit trails, retention enforcement, encryption key management, access logging, backup verification and a region constraint costs materially more per unit than ordinary storage, and the multiplier lands on volume. The volume in a connected product is dominated by telemetry and analytics events, which are usually the data with the weakest claim to needing it.

So bundling produces a specific and avoidable outcome. The cheapest-to-govern data is a rounding error by volume and the highest-volume data is paying the governed rate for no benefit. I have seen this dominate an infrastructure bill, and the fix is not a cheaper vendor. It is a correct classification, which should have happened at the start.

Separating also narrows the surface that the expensive controls apply to, which makes the expensive controls better. A small governed store with a real audit trail and a verified retention policy is both cheaper and more defensible than a large one where the controls were applied broadly and therefore shallowly. The same logic applies to processing, which is why data classification per field changes the residency problem in where your inference actually runs.

Bundling in the other direction is also a failure, and it is worse. Putting governed data into a general-purpose store because that is where the application already writes means the obligations apply and the controls do not exist. That is not a cost problem. That is a finding.

Jurisdiction as a constraint on storage region

Where the official copy may physically live is often not your choice. Depending on the regime, health or personal data may be required to stay within a territory, or transfers out may require a specific mechanism, or a public-sector customer may impose a location condition by contract.

The practical consequences are concrete.

Region constrains vendor and service choice. Not every managed service is available in every region, and the ones that are may lag on features. A constraint discovered after the architecture is built removes options you have already built on.

Multi-region means multi-record, or it means replication with rules. If two jurisdictions each require local storage, you either run separate records per jurisdiction, with all the identity and reconciliation work that implies, or you design a replication scheme that satisfies both. Both are substantial. Neither is a configuration change.

Residency for storage and residency for processing are separate questions. Storing the record in a region says nothing about where it is processed, including by any model call in your pipeline. Establish both.

The jurisdiction can change after you ship. A new market, a new customer class, a change in the applicable rules. Keeping the system-of-record table explicit, with the region constraint as a column, is what makes that a bounded change rather than an archaeology exercise.

What the applicable rules actually require for your product, data types and markets must be established with people who know that regime, and re-verified when you enter a new market or when the rules are amended. Do not carry a residency conclusion from one project to another.

The honest limit

This decision is high leverage and it is not irreversible everywhere. Moving the system of record for a low-volume, low-obligation data category is ordinary work. What is genuinely expensive is moving a high-volume governed category, or becoming the holder of record for something you previously only displayed, because that is a migration with history, reconciliation and a trust question attached, and a migration is not a build.

Splitting by datum has a real cost of its own. More stores, more interfaces, more ways for copies to disagree, and a reconciliation obligation between them. If you split into many categories with many holders, you have traded a cost problem for a consistency problem. The judgement is to split along the lines where the obligations genuinely differ and no further.

The cost argument also depends on your volumes. For a product with modest data and no telemetry, the bundled posture may be cheaper in total than the engineering required to separate concerns. The argument bites when volume is dominated by ungoverned categories, which is typical for connected devices and not universal.

Lastly, this piece addresses who holds the official copy. It does not address whether that holder's data is any good, and a correctly assigned system of record full of wrong values is still wrong.

FAQ

What does system of record mean in practice? It is the system whose copy wins when two systems disagree. Holding it brings three things: the compliance obligations such as retention, audit trail and production on request, the responsibility for corrections, and the integration surface that everyone else reads from. A product that holds no record of its own is a client to someone else's record, whatever its interface suggests.

Why decide this per piece of data rather than for the whole product? Because the correct answer differs by category. Clinical observations may belong in an existing clinical system while device telemetry has no other candidate holder, consent records belong with the governed record because they are evidence, and preferences are yours alone. One answer for the whole product forces the wrong posture onto most of the data.

How does bundling increase cost? Mixing governed and ungoverned data in one store makes the whole store inherit governed treatment, which is priced materially higher per unit for audit trails, retention enforcement, key management, access logging and region constraints. Volume in a connected product is dominated by telemetry and analytics, which have the weakest claim to needing any of it, so the multiplier lands exactly where it is least justified.

What is the quickest way to work out the right holder for a datum? Follow the correction path. The system where a human fixes a wrong value is almost always the right system of record, no matter how many places display it. Two other defaults help: where the datum originates, and which organisation is obliged to produce it on demand over a retention period.

How does jurisdiction constrain this? It can dictate the region in which the official copy may live, which in turn constrains which managed services and vendors are available and which features you can use. Two jurisdictions each requiring local storage means either separate records per jurisdiction or a replication design that satisfies both, and both are substantial work rather than configuration.

Can the decision be changed later? For low-volume, low-obligation categories, yes, routinely. What is expensive is moving a high-volume governed category, or becoming the holder of record for data you previously only displayed, because that is a migration carrying history, reconciliation and a correctness burden. Keeping the per-datum table explicit from the start is what keeps later changes bounded.