build.allanninal.dev

Part 4 of 7 · AWS autoposting series ~4 min read

How the Drive folder powers everything

The client edits a Google Doc. The system updates itself — with a safety layer that keeps the old version live if anything looks broken.

The client’s editing surface is Google Drive — a tool they already know. They never see a dashboard, never click a deploy button, never file a ticket. They open a doc, edit, save. A few seconds later the live system reflects the change.

Knowledge base sync pipeline from Google Drive to S3 Vectors A Google Drive folder containing four documents (FAQs, pricing, promos, do-not-say list) sends a push notification down to a Sync Lambda. The Sync Lambda validates the change. If validation fails, a comment goes back to the Drive doc and the old version stays live. If validation passes, the document is saved to a versioned S3 raw knowledge base bucket. An S3 PutObject event triggers a Chunker Lambda which splits the markdown and embeds each chunk via Bedrock Titan. The result is written to an S3 Vectors index, which the Reply robot reads from. Google Drive folder edited by the client — their authoring surface 01_faqs.gdoc · 02_pricing.gdoc 03_promos.gdoc · 04_do_not_say.gdoc service account has read-only access push notification Sync Lambda via Lambda Function URL exports doc · validates content If invalid comment back to Drive doc if invalid if valid S3 raw KB versioned · one-click rollback PutObject event Chunker + Embed ~500-token chunks Bedrock Titan S3 Vectors index the “shared brain” ← read by Reply robot
Fig 4. Drive is the source of truth; S3 is what the live system reads from.

Four docs, one job

The folder always has the same four documents:

  • FAQs — the questions customers ask all the time, with the actual answers.
  • Pricing — service tiers, what each costs, what’s included.
  • Promos — current campaigns with start and end dates.
  • Don’t-say list — topics to avoid, things to escalate to a human, refusals.

The shape never changes. Only the contents do. The system knows where to look for what.

Why a safety check first

If the client breaks something — deletes the pricing table, leaves a section blank, pastes formatting that breaks the parse — the live system shouldn’t go down with them. So before anything is saved to S3, a small validator runs:

  • Markdown parses cleanly
  • Required sections are present
  • Pricing table is structurally intact

If the validator complains, nothing is saved. The Sync Lambda writes a comment back into the Drive doc itself: “Pricing table looks empty — check rows 4–6.” The old version of the knowledge base stays live until the doc is fixed.

Why Drive isn’t on the hot path

Replies read from S3, never from Drive directly. A Drive outage doesn’t take the live page down. Drive’s API rate limits can never throttle the customer-facing reply path. Drive is the editing surface; S3 is the runtime surface. They’re decoupled by design.

Versioning is free safety

S3 versioning is enabled on the raw KB bucket. Every save is a new version. Rolling back a bad change is one click in the AWS console — no “restore from backup” ritual, no recovery point objective math, no engineer needed at 2am.

The client’s feedback loop is the doc itself

The client never logs into AWS. They never see a dashboard. The only place they get feedback is the doc they’re editing:

  • “Live as of 14:23” — their change is now in production.
  • “Pricing table is missing values in row 5” — their change was rejected; here’s why; here’s where to look.

That’s the entire interface. They already know how to use Google Docs. There’s nothing else to learn.

All posts