Sampreeth Avvari
Resume
Read the story

Architecture

Turns every survey into PDFs and emails.Retries until each step lands.

A survey submit becomes one named Cloud Task; the renderer draws the patient summary and the doctor report in headless Chromium, records each delivery step, and mails the patient and the office list. The CDF dashboard and an hourly sweep call the same service, and it tells the CDF when an intake is done.

60 to 90 s

for one survey's whole delivery, run inside the request with full CPU

Held

a patient email whose address is on file only for other patients in the Denticon mirror

7 min

from the first renderer commit at 11:00 PM on Jun 19 to the service running on Cloud Run

3 callers

the delivery queue, the CDF dashboard and the hourly sweep, each with a Google identity token

New York --:-- simulated

A survey is submitted
PDF Renderer A survey submit becomes one named Cloud Task; the renderer draws the patient summary and the doctor report in headless Chromium, records each delivery step, and mails the patient and the office list. The CDF dashboard and an hourly sweep call the same service, and it tells the CDF when an intake is done. CDF dashboard regenerate, old forms Vertex Gemini retry, then next model CDF intake events ack or try again Patient surveys intake, experience Cloud Tasks named task, 10 tries OIDC PDF renderer Chromium per render Gmail patient, clinic, alerts Patient and office summary, both reports Cloud Scheduler hourly reconcile Denticon mirror whose email is it Firestore, Storage PDFs, delivery record submit two emails regenerate sweep reports email lookup intake done each step

Hover a part to trace what it touches. Click it for its notes.

  • Built by me
  • Managed by Google
  • Outside system
  • Main data path
  • On demand
  • Credentials cross

When it breaks

What each failure does, and what it does not do.

  1. Delivery dies halfway

    The renderer answers 500 while anything is missing, the queue comes back, and each retry skips what already landed. Nobody gets an email twice.

    apps/pdf-renderer/src/server.ts:322

  2. The queue gives up

    The hourly sweep reads seven days of submissions and sends whatever never landed, under the same rules. Running it twice is a no op.

    apps/pdf-renderer/src/reconcile.ts:1

  3. The CDF is down

    Nothing about the patient or office email waits on it. The event retries for about 25 minutes, then one alert goes out.

    apps/pdf-renderer/src/cdf-notify.ts:20

What I tuned

Small choices that keep it fast and cheap.

  1. Work inside the request

    Delivery used to run after the reply, and Cloud Run throttled the CPU, so it crawled or vanished. It now runs inside the request with a live connection holding the instance.

    apps/pdf-renderer/src/server.ts:322

  2. CPU always on

    CPU stays allocated after the reply. Under the default throttling, work after the reply crawled and then died with the instance.

    infra/cloudbuild.pdf-renderer.yaml:46

  3. Eight renders an instance

    Each render forks a browser of about 300 MB, so Cloud Run spreads surveys across instances instead of piling them onto one.

    infra/cloudbuild.pdf-renderer.yaml:52

Guards

Rules the code enforces, not rules people remember.

  1. Whose email is it

    An address on file only for other patients holds the patient email and tells the office. The practice's own inboxes are never held.

    apps/pdf-renderer/src/email-owner.ts:23

  2. Only an ack counts

    The CDF event is delivered when the CDF answers ack. Every other answer says whether another try could help.

    apps/pdf-renderer/src/cdf-notify.ts:9

  3. Callers sign every call

    The service is deployed with no public access. The queue, the sweep and the CDF each present a Google identity token.

    infra/cloudbuild.pdf-renderer.yaml:27