DEV Community: Mary Olowu

I Renamed a Hot Postgres Table Without Dropping a Request

Mary Olowu — Thu, 21 May 2026 15:23:19 +0000

Most table renames are database-easy and deploy-hard.

The SQL looked trivial:

ALTER TABLE oidc_clients RENAME TO oidc_provider_clients;

In PostgreSQL, that rename is fast and metadata-only.

The real problem was the rollout window around it.

This was a live IAM service on the login path, deployed across multiple pods. During a rolling deploy, there is always a period where some instances run the new code and some still run the old code.

During that window:

new pods query oidc_provider_clients
old pods still query oidc_clients

If you rename the table and do nothing else, old pods start failing with:

relation "oidc_clients" does not exist

The fix was a two-line compatibility shim:

ALTER TABLE oidc_clients RENAME TO oidc_provider_clients;
CREATE VIEW oidc_clients AS SELECT * FROM oidc_provider_clients;

That was enough to let old pods survive the rollout window while new pods moved to the renamed table.

If the only thing that changed is the table name, the old name can keep working for another minute.

That was the whole trick.

The real failure mode

On a static database, ALTER TABLE ... RENAME is boring.

On a live service, the schema and application versions are temporarily out of sync by design:

the migration has already run
some pods still serve old code
some pods already serve new code

That mismatch window is where destructive naming changes fail.

The usual options are:

accept a maintenance window
do a multi-release expand/contract migration with dual writes
add a short-lived compatibility layer

For a pure rename, option 3 is much cheaper than the other two.

The shim

Right after the rename, create a view with the old name:

ALTER TABLE oidc_clients RENAME TO oidc_provider_clients;
CREATE VIEW oidc_clients AS SELECT * FROM oidc_provider_clients;

Now old code can keep using the old relation name:

SELECT * FROM oidc_clients WHERE "workspaceSlug" = 'acme';

And new code can use the new one:

SELECT * FROM oidc_provider_clients WHERE "workspaceSlug" = 'acme';

When the rollout finishes and no old pods remain, drop the view in a follow-up migration.

For a rename, that is exactly the kind of temporary compatibility boundary you want.

The part people miss: writes

The first reaction to this pattern is usually:

"Fine for reads, but views are read-only."

That is not true for simple PostgreSQL views.

PostgreSQL automatically makes a view updatable when it is simple enough, which in practice means:

one table in the FROM
no GROUP BY, DISTINCT, HAVING, LIMIT, OFFSET
no set operations
no aggregates or window functions

For a shim like this:

CREATE VIEW oidc_clients AS SELECT * FROM oidc_provider_clients;

INSERT, UPDATE, and DELETE route to the base table automatically.

So old code like this still works during the rollout window:

UPDATE oidc_clients
SET revoked = true
WHERE "workspaceSlug" = 'acme';

DELETE FROM oidc_clients
WHERE "workspaceSlug" = '__some_test__';

There is no trigger to write. No dual-write logic. No extra application routing code.

You still get the normal locks and write behavior of hitting the base table. You just do not have to build extra migration machinery to keep the old name alive for 60 seconds.

The objection that mattered

One reviewer raised the real objection:

what about INSERT ... ON CONFLICT DO UPDATE?

That was not hypothetical. One old path still did an upsert against the old relation name.

The concern looked legitimate because a lot of older advice around updatable views says they do not support ON CONFLICT, and search results still surface that warning.

So I tested it directly before complicating the migration.

What I tested

With the renamed table and compatibility view in place:

ALTER TABLE oidc_clients RENAME TO oidc_provider_clients;
CREATE VIEW oidc_clients AS SELECT * FROM oidc_provider_clients;

I ran an upsert through the view:

INSERT INTO oidc_clients ("clientId", metadata)
VALUES ('test_x', '{"v":1}'::jsonb)
ON CONFLICT ("clientId")
DO UPDATE SET metadata = EXCLUDED.metadata;

Then I ran it again with different data to force the conflict path:

INSERT INTO oidc_clients ("clientId", metadata)
VALUES ('test_x', '{"v":2}'::jsonb)
ON CONFLICT ("clientId")
DO UPDATE SET metadata = EXCLUDED.metadata;

Both statements succeeded. The row landed in oidc_provider_clients, and the second statement updated the existing row as expected.

We verified it on PostgreSQL 16.12 in production and 16.13 locally.

The current PostgreSQL docs for CREATE VIEW also say that INSERT statements with ON CONFLICT UPDATE are fully supported on automatically updatable views.

So if your shim is a simple single-table view, modern Postgres can carry more of the rollout than a lot of engineers assume.

Why this beats expand/contract for a pure rename

Expand/contract is still the right answer when the shape changes:

new columns with new semantics
type changes
split or merged fields
different write paths

But for a pure rename, dual-write is wasted complexity.

You are not changing where the data logically lives. You are changing the name application code uses to reach it.

That is exactly the kind of mismatch a short-lived compatibility view is good at absorbing.

If PostgreSQL can cheaply preserve compatibility during the rollout, I would rather buy compatibility than orchestrate a bigger migration plan.

When I would use this

This pattern is a good fit when all of these are true:

the old and new code need the same row shape
the compatibility layer can be a simple single-table view
you only need the shim for the duration of a rolling deploy
the real change is a rename, not a semantic rewrite

When I would not

Do not use this as a magic answer for every migration.

It stops being the right tool when:

the view would need joins or aggregates
old and new code disagree on column names or types
the application depends on shape changes the view cannot hide
you need a long-lived compatibility contract instead of a short-lived rollout shim

One subtle caveat: SELECT * in a view captures the column list at view creation time. Fine for a short-lived rename shim. Another reason not to turn this into a permanent abstraction.

What the rollout looked like

In our case, the release did two things:

archive and delete stale legacy rows
rename the table and create the compatibility view

The first new pod applied the migration. Old pods kept serving traffic against oidc_clients, which was now a view. New pods used oidc_provider_clients. Kubernetes finished rolling the old pods out. Then we removed the shim in a later migration.

No maintenance window.
No dual-write phase.
No dropped login traffic during the rollout.

The takeaway

The rule I would reuse is simple:

If the only thing that changed is the table name, make the old name keep working until the rollout is over.

In PostgreSQL, the cheapest version of that rule is often:

ALTER TABLE old_name RENAME TO new_name;
CREATE VIEW old_name AS SELECT * FROM new_name;

That is a small trick.

It is also the kind of trick that turns a risky production rename into a boring deploy, which is the whole point.

LLMs Are Probabilistic. Your Workflow Shouldn't Be.

Mary Olowu — Wed, 20 May 2026 14:05:57 +0000

Most AI app demos make the same mistake:

they treat the model like the application.

Prompt in, answer out, maybe a few tool calls, then everybody acts surprised when the thing becomes weird in production.

The problem is not that the model is useless.

The problem is that we keep asking a probabilistic component to behave like deterministic workflow code.

That is the wrong boundary.

The better pattern is simpler:

let the model interpret
let software validate
let the workflow own state
let high-risk actions require approval

If you remember nothing else, remember this:

Do not let the model own irreversible state transitions.

Why This Matters

The reliability problem is not hypothetical anymore.

Stanford HAI's 2026 AI Index reports that in a new accuracy benchmark, hallucination rates across 26 top models ranged from 22% to 94%. The same report says documented AI incidents rose from 233 in 2024 to 362 in 2025.

And yet adoption keeps rising. In the 2026 AI Index economy chapter, 88% of surveyed organizations reported using AI in at least one business function in 2025, and 79% reported regular generative-AI use in at least one function.

So yes, teams are shipping this stuff.

But the same chapter also says scaled AI-agent use stayed in the single digits across nearly all business functions.

That makes sense. People want the upside of LLMs without letting them quietly become the database, the rules engine, and the compliance department at the same time.

Even the Model Vendors Are Telling You This

Anthropic's "Building Effective Agents" says the most successful implementations they saw used simple, composable patterns, and draws a clear line between:

workflows, where LLMs and tools are orchestrated through predefined code paths
agents, where models dynamically direct their own processes and tool usage

They also recommend starting with the simplest solution possible and only adding complexity when needed.

OpenAI says something similar in a different way. In the Structured Outputs launch, they explicitly note that model behavior is inherently non-deterministic, and that better model performance alone still did not meet the reliability developers need for robust applications. Their answer was not "prompt harder." It was deterministic constrained decoding around model output.

That is the pattern.

Use the model where probability is acceptable.
Use deterministic engineering where correctness has to be enforced.

The Architectural Rule

Here is the rule I trust:

LLMs should propose actions. Software should decide whether those actions are allowed.

That means the model is great for:

intent extraction
document understanding
summarization
classification
drafting
tool selection in bounded contexts

And it should usually not be the final authority for:

permissions
pricing
payment execution
account state
refunds
contract interpretation
compliance gates
destructive writes

If the model says "refund this order," that is not a refund. That is a recommendation.

Your application should still check:

does the order exist?
is it refundable?
is the amount within policy?
does the caller have permission?
is there already a refund in flight?
does this require human approval?

That logic belongs in code, not in hope.

The Boring Architecture That Wins

This is the stack I would trust in production.

1. LLM as interpreter

The model turns unstructured input into a candidate action:

{
  "intent": "issue_refund",
  "order_id": "ord_123",
  "reason": "duplicate_charge",
  "amount": 49.0
}

2. Typed output contract

Do not parse vibes. Parse a schema.

OpenAI's Structured Outputs guide exists for a reason: even when model quality improves, you still need deterministic enforcement around output shape.

3. Deterministic validator

Now your real application runs checks:

schema validation
authz
business rules
idempotency
resource existence
threshold checks
rate limits

4. Workflow engine or state machine

The model does not own the state transition. Your workflow does.

For example:

requested -> validated -> approved -> executed -> recorded

If validation fails, the workflow branches. If approval is required, it pauses. If execution fails, it retries or dead-letters.

5. Scoped tools

Tools should be narrow, explicit, and permissioned.

OpenAI's practical guide to building agents recommends assessing tool risk based on things like write access, reversibility, and financial impact, then pausing or escalating to a human for high-risk functions.

That is not compliance theater. That is basic architecture.

6. Tracing, logs, and evals

If you cannot inspect which prompt, tool result, validation step, and branch decision led to an action, you are not debugging a system. You are guessing.

The Anti-Pattern

Here is the version I do not trust:

User message goes straight to agent.
Agent decides what the business rule probably is.
Agent writes to the database.
Agent sends the email.
Agent updates the CRM.
Everybody hopes the prompt was good enough.

This looks fast in a demo because all the complexity is hidden.

It breaks in production because all the accountability is hidden too.

When something goes wrong, you will not know whether the failure came from:

bad retrieval
bad prompt assumptions
stale tool data
missing permission checks
race conditions
duplicate writes
a plain old hallucination

And worse, you may not know until after money moved or customers were contacted.

NIST Is Basically Handing You the Blueprint

NIST's AI Risk Management Framework is not just policy paperwork. It is practical engineering guidance if you read it that way.

Some of the most useful parts for builders:

define and differentiate human and AI roles
document knowledge limits and how outputs will be overseen
test systems before deployment and regularly in production
monitor functionality and behavior in production
make sure systems can fail safely beyond their knowledge limits
document risks, controls, and third-party dependencies

That is just good software engineering with a better vocabulary.

NIST's Generative AI Profile goes further and says generative AI may require additional human review, tracking, documentation, and management oversight.

Which is exactly what experienced teams discover after the first few production incidents anyway.

A Good Mental Model

Think about the LLM as a perception layer, not a transaction layer.

It helps you turn messy human input into structured candidates.

It does not get to redefine the core invariants of your system.

So instead of this:

model -> action

Build this:

model -> proposal -> validation -> policy check -> approval (if needed) -> execution -> audit log

That extra machinery is not bureaucracy.

It is the difference between an AI feature and an AI system you can trust.

What I Would Build First

If I were building an AI workflow today, I would start in this order:

One narrow use case with real pain.
One model call that returns typed output.
One validator layer with explicit business rules.
One small set of tools with clear permissions.
One approval path for high-risk actions.
One trace per run.
One eval set based on real failures, not synthetic optimism.

Anthropic's guidance to start simple is right. OpenAI's guardrail guidance is right. The teams getting burned are usually the ones skipping the boring layers because the model looked good in staging.

The Take

AI does not remove the need for software architecture.

It raises the price of getting architecture wrong.

LLMs are powerful because they handle ambiguity well. They are dangerous when you let that ambiguity leak into the parts of your system that are supposed to be exact.

So let the model read.
Let the model classify.
Let the model draft.
Let the model suggest.

But let deterministic systems own:

truth
policy
permissions
state transitions
side effects

AI makes mistakes.

That is not a reason to avoid building with it.

It is a reason to build the part around it like an engineer.

Sources

Stanford HAI, 2026 AI Index, Responsible AI chapter: https://hai.stanford.edu/ai-index/2026-ai-index-report/responsible-ai
Stanford HAI, 2026 AI Index, Economy chapter: https://hai.stanford.edu/assets/files/ai_index_report_2026_chapter_4_economy.pdf
Anthropic, "Building Effective Agents": https://www.anthropic.com/engineering/building-effective-agents
OpenAI, "Introducing Structured Outputs in the API": https://openai.com/index/introducing-structured-outputs-in-the-api/
OpenAI, "A practical guide to building agents": https://openai.com/business/guides-and-resources/a-practical-guide-to-building-ai-agents/
NIST AI RMF Core: https://airc.nist.gov/airmf-resources/airmf/5-sec-core/
NIST Generative AI Profile (NIST-AI-600-1): https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf

What an AI Agent's Memory Layer Actually Has to Store

Mary Olowu — Mon, 18 May 2026 19:17:35 +0000

AI agents do not usually break mature codebases because they cannot write code.

They break them because they forget why the code is shaped the way it is.

They forget the package boundary.
They forget the feature shipped, but it is still flagged off.
They forget we are only halfway through a multi-stage migration.
They forget that one abstraction already caused problems once.

Then a later session makes a locally reasonable change that is globally wrong.

When people talk about AI memory, the conversation often drifts toward the same
idea:

give the agent more.

More chat history.
More docs.
More logs.
More old reasoning.

That is why I am skeptical of the idea that better AI memory means storing more.

If all of that just turns into a larger pile to drag from session to session,
the memory layer becomes a junk drawer.

The agent has "more context," but the work does not get more coherent.
It just gets noisier.

I think the goal is much narrower:

an AI-assisted project needs to preserve the small set of durable facts that are
load-bearing later.

Not everything.
Just the things that stop a later session from making a locally reasonable and
globally wrong decision.

Most project context is temporary.

The exact wording of a prompt is temporary.
The full output of a log search is temporary.
The back-and-forth while exploring an implementation is temporary.
The rough dead ends you hit during one session are mostly temporary too.

What actually needs to survive is a much smaller set.

For me, it looks something like this:

decisions
boundaries
authoritative sources
failure modes
mandatory conventions

That is the real memory layer.

Decisions are the obvious one.

Not "we discussed this once."

I mean:

what was decided
why it was decided
whether it is still active
what it replaced
what is now off the table

That last part matters more than people admit.

If a new decision supersedes an old one, the relationship has to be explicit.
Otherwise every later session has to guess whether the old rule is still alive.

A memory layer also has to store status.

I hit this recently on a staged release.

One release shipped the metrics and observer path for a future cutover, but the
actual cutover was still dormant. The next step was not "start the future
implementation." The next step was "watch the baseline for the agreed window,
then decide."

That is a very different kind of memory.

The important fact was not just that code had shipped.

It was:

this capability is live but still dormant
the follow-up is intentionally blocked for now
we are in the observation window
the earlier decision has not been superseded yet

Without that state recorded somewhere durable, a later session can easily treat
"the metrics shipped" as "the gate is cleared" and start nudging the project
forward too early.

Boundaries are the next thing.

This is where a lot of mature-repo drift starts.

The code the agent writes can be perfectly competent and still be wrong because
it landed in the wrong layer.

The package that defines canonical query types should not quietly become the
package that knows about one storage engine.
The service that owns orchestration should not quietly absorb unrelated business
logic just because the local edit looked convenient.

A useful memory layer needs to preserve those boundaries in plain language:

what belongs here
what does not belong here
where the adjacent responsibility actually lives

Authoritative sources are another big one.

Projects often have several places that mention the same thing:

code
docs
tickets
release notes
generated configs

If the agent cannot tell which source actually owns a field, a state transition,
or a behavior contract, it can make a change that looks harmless and still
quietly violate the system.

The project has to say, somewhere durable:

this path owns this behavior
this service is authoritative for this record
this generated file should not be hand-edited
this contract is defined here, not inferred from nearby code

Failure modes are the other kind of memory people under-capture.

Some of the most valuable project knowledge is not "how it works."

It is:

what broke before
which direction created drift
which retry shape caused trouble
which abstraction looked elegant and turned into a maintenance tax

If that only lives in one old chat or in your head, the agent will keep
rediscovering the same trap with total confidence.

Mandatory conventions matter too.

Not every common pattern is a rule.
Not every rule can be inferred from code.

Some things really are optional style preferences.
Some things are hard constraints.

If the agent cannot tell the difference, it will treat both like vibes.

A good memory layer should also encode when the agent must pause and ask for
human review.

Some decisions should not be made autonomously at all. Introducing a new Kafka
consumer, creating a new RPC boundary, changing auth or billing behavior,
removing backward compatibility, or adding a new queue or datastore are not
just implementation details. They are moments where the project should require
human judgment on purpose.

That is why I think the useful memory question is not:

"How do I make the agent remember more?"

It is:

"What absolutely has to survive a fresh session?"

That is a much better filter.

It also makes the "what not to store" side much clearer.

A durable memory layer probably does not need:

every exploration path
every copied stack trace
every draft explanation
every implementation detail from every task
giant transcript dumps pretending to be knowledge

Those things belong in the window while you are working.
They do not all belong in the store.

This is why I keep coming back to one idea:

memory without a schema is just a bigger transcript.

And bigger transcripts rot.

They get longer.
They get noisier.
They become expensive to reread.
They make retrieval harder.
They turn "remember this" into "search this pile and hope."

Structured memory is less exciting to talk about.

It is also much more useful.

A small, boring memory layer with decisions, boundaries, ownership, and failure
modes will usually beat a richer but sloppier pile of context.

That does not have to mean some grand new platform.

It could be:

a few markdown files
a strict JSON ledger
a tiny SQLite table
a set of durable docs with clear update rules

The implementation matters less than the shape.

The shape is the point.

And it should not grow forever without judgment.

Some memory stops being useful because the project has moved on.

A boundary gets replaced.
A migration completes.
A temporary constraint expires.
A failure mode gets designed out.

If those records stay mixed in with the live ones forever, the memory layer
slowly turns back into the same clutter problem it was supposed to fix.

So part of a healthy memory layer is occasional pruning.

Not deleting history recklessly.

I mean deliberately:

archiving records that are no longer active
marking superseded decisions clearly
removing stale task-local notes from durable memory
keeping the live memory surface small enough to stay high-signal

That matters for quality and for cost.

A smaller, cleaner memory layer is easier to query, easier to trust, and easier
to carry forward across sessions.

If your AI sessions keep feeling like first contact, I do not think the answer
is automatically more memory.

It may just be better memory.

What is the smallest set of durable records that would stop your project from
forgetting itself between sessions?

AI Can Write the Code. It Still Forgets the Decisions That Matter.

Mary Olowu — Thu, 14 May 2026 18:20:17 +0000

A lot of AI coding advice quietly assumes the same thing:

if the output is bad, you probably need a better model, a better prompt, or more tooling.

Sometimes that is true.

But one AI coding failure keeps showing up for me, and I do not think a better model is the real fix.

In one session, we make a decision that is supposed to guide the rest of the project.

Then in a later session, the model answers that same question differently and starts nudging the project down another path.

Usually it is more subtle than "the code is wrong."

We already decided that deprecated paths stay backward compatible for a reason, that receivers fan out to downstream consumers instead of owning business logic inline, and that idempotency gets enforced before side effects fire. Then a later session solves the local task as if those decisions were optional because it only sees the immediate diff.

Nothing is obviously broken right away.

The code still looks competent.
It still compiles.
It still sounds reasonable.

But the project starts to feel scattered.

It no longer feels like one person with memory has been carrying the work forward.

That changed how I think about AI coding.

On an ongoing project, the bigger issue is often not generation quality. It is continuity.

The model does not know:

which decision had already been made
which tradeoff we had already accepted
which docs were still authoritative
what had changed recently
what should not be changed again

That is not really an intelligence problem.

It is a memory problem.

I feel this most on a solo-dev monorepo, where I am not just using AI for one-off code generation. I am also using it for backlog triage, bug capture, planning, reports, and picking work back up across sessions.

The frustrating part is not that the model cannot code.

It is that it can code while waking up without durable context.

Sometimes the missing memory is shallow and local.

A simple rule in the codebase or in CLAUDE.md helps a lot:

follow the existing conventions
match the existing code patterns
use FIFO here, not LIFO
do not add a second library when the current one already covers the job

That kind of memory is useful and surprisingly high leverage.

But the harder problem is when the missing memory is much deeper than code style.

It is about remembering why the project should not go a certain direction again.

Things like:

deprecated behavior stays backward compatible until the migration path is actually complete
receivers fan out work instead of embedding downstream business logic directly
idempotency has to happen before side effects, not after them
this webhook should update the existing record, not create a second one
this state transition only happens after this other condition is true
duplicate events should be absorbed here, not after side effects have already fired
this source is authoritative for this field, so do not let another path quietly overwrite it
this module already has a helper for this logic, so do not bypass it and create a second path
do not bring in a new dependency to solve a problem the existing stack already solves
do not create a retry flow that can turn into an infinite loop
do not quietly undo an earlier system decision because the current session cannot see its history

Those decisions are usually load-bearing.

They were made for a reason.

Forgetting why they exist is a bit like forgetting why a house has support pillars in the frame. Once the reason disappears, the pillar starts to look optional. Then removing it or building around it the wrong way starts to feel harmless, right up until the cost shows up somewhere else.

This is where AI-written code starts to feel different from human-guided code.

A person with memory usually carries more invisible continuity into the work.

They remember:

why the earlier choice was made
what problem we were trying to avoid
which convention is mandatory versus just common
which "reasonable" branch is actually the wrong one for this project

Without that continuity, AI can produce code that looks fine in isolation while introducing costly mistakes into the project over time.

If the model keeps re-litigating the same decision, reopening the same tradeoff, or proposing work that was already decided against, the problem is not just generation quality. The system has no reliable memory layer.

That is why I have become much more interested in boring project context than in prompt tricks.

What helped me was giving AI a few stable places to look:

short repo guardrails
maintainers docs for durable context
lightweight local memory for session continuity
real systems of record for backlog and releases
explicit notes about patterns to keep following and failure modes to avoid

None of that is glamorous.

It is also what made the biggest difference.

Once I had that structure, the sessions stopped feeling like first contact every time.

The model still made mistakes. It still needed review. It still needed boundaries.

But the failures got more honest.

Instead of "the AI is useless," the problem became easier to diagnose:

the memory is stale
the docs are weak
the workflow has no source of truth
the instructions are doing the job that documentation should be doing
a deeper architectural rule is being treated like a surface-level style preference

That is a much better problem to have because you can actually fix it.

I think a lot of AI coding frustration is really project-memory failure wearing a model-shaped mask.

People keep trying to solve it with one more model upgrade or one more agent when the actual missing piece is memory that survives the chat window.

That does not mean model quality is irrelevant.

It means there is a ceiling on how useful any model can be if the project keeps forgetting its own load-bearing decisions.

The shift for me was simple:

I stopped asking, "How do I make the model smarter?"

I started asking, "How do I stop a later session from quietly taking the project in a different direction?"

The future of AI coding is not just better generation.

It is better memory around the decisions that hold the work up.

What breaks AI coding more often in your projects: weak generation, or weak continuity?

I Stopped Using Claude Code as a Giant Prompt and Started Using It as Project Ops

Mary Olowu — Wed, 13 May 2026 03:54:37 +0000

If you use Claude Code on a real project for more than one-off coding tasks, you eventually hit the same wall:

the model is good at solving the task in front of it, but every new session still has to reconstruct the project.

For me, that got especially annoying in a solo-dev monorepo. I was not just asking Claude to write code. I was also using it for:

backlog triage
bug capture
planning the next task
weekly status summaries
preserving decisions across sessions

At some point I realized I was trying to solve a workflow problem with a better prompt.

That was the wrong move.

What helped was building a thin project-ops layer around Claude Code instead.

My current version uses Jira MCP for backlog work, Confluence for published reports, a local JSON context DB for working memory, maintainer docs for durable context, and a few commands like /standup, /bug, and /rfe.

Then I pulled the reusable parts into a public starter repo without shipping the private project details around them.

The repo is here: restofstack/claude-project-ops-starter.

TL;DR

The useful part of my setup is not one giant prompt.

It is:

a short CLAUDE.md for guardrails
a docs/maintainers/ folder for durable project context
a tiny local JSON file for rolling memory
real systems of record for backlog, PRs, and releases
reusable commands for common project-ops tasks

That is the pattern I extracted into a public starter repo.

The Problem With Default AI Usage on Ongoing Projects

The default interaction pattern looks like this:

open Claude Code
paste context
explain the task
repeat tomorrow

That is fine for isolated implementation work.

It breaks down when each session has to renegotiate:

what matters in the repo
where architecture context lives
what work is already in progress
which tools are authoritative
how status should be reported

Once a project is large enough, "just paste more context" stops being a serious strategy.

The Structure I Ended Up With

This is the rough shape:

CLAUDE.md
docs/
  maintainers/
    README.md
    overview/
    development/
.workspace-temp/
  context-db.json
.claude/
  commands/
    standup.md
    bug.md
    rfe.md
    reflect.md
    weekly-report.md

Each part has a different job.

1. `CLAUDE.md` Is for Rules, Not Everything

I keep CLAUDE.md short and boring on purpose.

It only contains the repo-level rules that should apply in every session, things like:

prefer the existing system of record over invented state
finish work in progress before proposing new work
never fabricate backlog items or counts
keep outputs concise and actionable

That file is not where I put architecture notes, runbooks, or a giant project brain dump.

If you overload it, both you and the model stop trusting it.

2. `docs/maintainers/` Holds the Durable Context

Anything that should survive beyond a session goes into maintainers docs:

system overviews
service boundaries
local development notes
runbooks
release notes

This gives Claude a clean place to start, and it has a side benefit: the docs also become useful to humans.

That matters more than it sounds. If a doc is good enough for future-you, it is usually better context for AI too.

3. Local JSON Memory Is Good Enough

I use a small local JSON file for rolling working memory.

Not a service. Not a database product. Just a file.

It stores a few useful things:

what shipped recently
branch or PR context
decisions worth remembering
estimate patterns

This has been the right level of complexity for solo work because it is:

cheap
easy to inspect
easy to edit
easy to replace later

I also use a /reflect command to append small memory items instead of trying to manually maintain that file all the time.

4. Real Systems of Record Stay Real

Claude should not become your shadow Jira, shadow GitHub, or shadow release tracker.

The actual source of truth should stay in the actual system:

Jira, GitHub Issues, Linear, or whatever you use for backlog
PR system
release history
docs or wiki

The AI should read from those systems and synthesize useful outputs. It should not replace them.

That boundary is what keeps the workflow practical instead of magical-and-fragile.

The Commands Were the Biggest UX Upgrade

The structure matters, but the commands are what made the whole thing usable day to day.

I extracted the workflows I kept repeating:

/standup
/bug
/rfe
/reflect
/weekly-report

And when I cleaned the setup for a public starter, a few surrounding workflows became part of the picture too: /checkpoint, /sanitize, /docs-sync, /release-notes, and /root-cause.

Each one has a defined job.

For example:

/standup checks memory, git state, PR state, backlog state, and maintainers docs, then recommends the next actions
/bug captures a clean bug report without turning it into a full debugging session
/weekly-report turns project signals into a durable report instead of a one-off chat response

That consistency removed a lot of prompt thrash.

Without commands, every request is basically a blank page. With commands, the common project tasks have defaults.

Where This Fits Relative to Spec Kit

I still use Spec Kit, and I do not think this starter replaces it.

Spec Kit is useful when I want to take one feature or product change and push it toward a clearer spec and implementation path.

This starter handles a different layer: working memory, maintainer docs, standups, bug and RFE capture, reports, handoff, and the repeatable repo workflows that help Claude pick up the thread again tomorrow.

So for me this fills a different gap than Spec Kit or other Claude "superpowers" style workflows.

Why This Was Especially Useful in a Monorepo

Monorepos create a context problem fast.

Even as a solo developer, I still need a reliable way to answer:

what changed recently?
what is in progress?
what got forgotten?
what should be picked up next?
what decisions should persist beyond this session?

I did not want to build a custom agent platform to solve that.

I also did not want to keep improvising.

This setup gave me a middle path.

The Portable Part

The original version of this workflow was tied pretty closely to my own stack.

The part worth sharing was the pattern, not the exact tools.

It also needed a cleanup pass before it was publishable. A real working setup usually contains things you should not ship as-is:

local Claude settings
project-specific IDs and URLs
live working memory files
internal naming conventions
backlog details that only make sense inside the project

That is why I split the starter into adapters like:

Jira + Confluence
GitHub Issues + repo docs
local JSON + markdown only

So if your stack is different, you can still keep the same model:

stable guardrails
durable docs
lightweight memory
real systems of record
repeatable workflows

That was the real extraction goal: publish the useful workflows, not the private residue of my specific project.

What I Would Recommend If You Try This

If you want to copy the idea, I would start with this:

Keep CLAUDE.md short.
Move durable project context into maintainers docs.
Use a tiny local memory file before building anything fancier.
Pick 3-5 workflows you repeat all the time and formalize them.
Keep the real backlog and release data in the systems you already trust.

That is enough to get most of the value.

Closing

The useful change was not "add more prompt."

It was "design better interfaces for the model."

That is what made Claude Code feel less like a clever autocomplete session and more like a practical project-ops layer for an ongoing codebase.

If you are already using AI on a real repo, that is where I think the leverage is.

Ingest Webhooks From Any Provider — GitHub as the Example

Mary Olowu — Sun, 10 May 2026 04:54:21 +0000

Centrali can store webhook events from any provider that sends HTTP POST requests. The signature settings are configurable per trigger, so each provider gets its own verification rules — Stripe, GitHub, Shopify, Twilio, or anything else.

This walkthrough uses GitHub as the example: one function, one trigger, signature verification, permanent storage. The same pattern works for any provider.

How GitHub Webhook Signatures Work

GitHub signs every webhook delivery with HMAC-SHA256. The signature arrives in the x-hub-signature-256 header, prefixed with sha256=:

x-hub-signature-256: sha256=d57c68ca6f92289e6987922ff26938930f6e66a2d161ef06abdf1859230aa23c

This is different from Stripe's compound header (t=...,v1=...), which is why signature settings are per-trigger rather than a global config. Every provider has its own format.

Step 1: Write the Store Function

In the Centrali console, go to Logic > Functions and create a new function called Store GitHub Event.

async function run() {
  const payload = executionParams.payload;
  const headers = executionParams.headers || {};

  const eventType = headers['x-github-event'] || 'unknown';
  const deliveryId = headers['x-github-delivery'] || null;

  const record = await api.createRecord('github-events', {
    eventType: eventType,
    deliveryId: deliveryId,
    sender: payload.sender?.login || null,
    action: payload.action || null,
    repo: payload.repository?.full_name || null,
    raw: payload,
  });

  api.log({ message: 'Event stored', eventType, repo: payload.repository?.full_name,
    recordId: record.data.id });

  return { success: true, recordId: record.data.id };
}

A few things to note:

executionParams.payload is the raw HTTP body GitHub sends. For HTTP triggers, this is the full POST body — no wrapping.
executionParams.headers gives you the request headers. GitHub puts the event type in x-github-event and a unique delivery ID in x-github-delivery.
The function flattens key fields (eventType, sender, repo, action) to the top level for easy filtering and keeps the full payload in raw.

Before running this, create a schemaless collection called github-events. Schemaless mode accepts any shape — a push event looks nothing like an issues event.

Tip: Want to follow along? Create a free workspace — this takes less than 5 minutes, no deployment required.

Step 2: Create the HTTP Trigger

Go to Logic > Triggers and create a new trigger.

Field	Value
Name	`github-webhook`
Function	`Store GitHub Event`
Type	`HTTP Trigger`
Path	`github`

This gives you a public webhook URL:

https://api.centrali.io/data/workspace/{your-workspace}/api/v1/http-trigger/github

Configure Signature Verification

GitHub uses a simpler signature format than Stripe — no compound header, no timestamp. Toggle Validate Signature on and configure:

Setting	Value
Validate Signature	On
Signing Secret	Your GitHub webhook secret (you'll set this in GitHub too)
Signature Header Name	`x-hub-signature-256`

Expand Advanced Signature Settings to see the extraction defaults:

Setting	Value
HMAC Algorithm	`sha256`
Digest Encoding	`hex`
Signature Extraction Regex	`sha256=(.+)`
Secret Encoding	`raw (default)`

The extraction regex sha256=(.+) strips the sha256= prefix from GitHub's header value, leaving just the HMAC digest for verification.

Note: GitHub doesn't include a timestamp in the signature header, so there's no replay protection timestamp to configure. If you need replay protection, you can enable it separately — Centrali will track delivery IDs and reject duplicates.

Step 3: Configure the Webhook in GitHub

Open your repository on GitHub. Go to Settings > Webhooks > Add webhook.

Field	Value
Payload URL	Your Centrali HTTP trigger URL
Content type	`application/json`
Secret	The same secret you entered in the Centrali trigger
Events	Choose which events to receive

Click Add webhook. GitHub sends a ping event immediately to verify the endpoint is reachable.

Step 4: See Your Data

Push a commit, open a pull request, or create an issue — any event you subscribed to. Then open the github-events collection in the Centrali console.

Click into any record to see the flattened fields and the full raw payload:

Toggle JSON editor to see the complete payload GitHub delivered:

You can verify the delivery on GitHub's side too. Go to your webhook settings and click Recent Deliveries — you'll see the response status and headers:

Note: After your first events arrive, run Schema Discovery on the github-events collection to turn the auto-detected fields into filterable, sortable columns.

The Pattern Works for Any Provider

The function + trigger pattern is the same regardless of the provider. The only things that change are:

Provider	Signature Header	Extraction Regex	Secret Format
Stripe	`stripe-signature`	`v1=([^,]+)`	`whsec_...` (raw)
GitHub	`x-hub-signature-256`	`sha256=(.+)`	Any string (raw)
Shopify	`x-shopify-hmac-sha256`	(entire header)	API secret (base64)
Twilio	—	—	Uses URL-based auth

For providers that don't sign webhooks at all, just leave signature verification off. The function and collection work the same way.

Query Programmatically

import { CentraliSDK } from '@centrali-io/centrali-sdk';

const client = new CentraliSDK({
  workspaceId: 'your-workspace',
  clientId: process.env.CENTRALI_CLIENT_ID,
  clientSecret: process.env.CENTRALI_CLIENT_SECRET,
});

// All push events
const pushes = await client.queryRecords('github-events', {
  'data.eventType': 'push',
});

// Events from a specific repo
const repoEvents = await client.queryRecords('github-events', {
  'data.repo': 'your-org/your-repo',
});

// Pull request events from a specific user
const userPRs = await client.queryRecords('github-events', {
  'data.eventType': 'pull_request',
  'data.sender': 'octocat',
});

What's Next

Store Stripe Webhook Events and Query Them Forever — the original walkthrough, if you want to add Stripe alongside GitHub
Get Alerted When a Stripe Charge Fails — add real-time alerting on top of stored events
Query Stripe Webhook Events Like a Database — advanced querying patterns that work with any collection
Your Webhook Data Is Schemaless — Here's How to Give It Structure — turn raw webhook JSON into typed, validated properties

Start building your own webhook pipeline

Add Webhooks to Your SaaS in 10 Minutes (Without Queues or Retries)

Mary Olowu — Mon, 04 May 2026 18:50:28 +0000

TL;DR — One API call subscribes a customer endpoint. Centrali signs each delivery with HMAC-SHA256, retries 5 times over ~40 minutes on failure, logs every attempt, and exposes a one-line replay endpoint. No queue. No retry logic. No Svix. The whole subscribe call is right below — scroll to it if you just want the shape.

Your customers want webhooks. You know the checklist:

A queue so user requests don't block on HTTPS calls to third-party servers
HMAC signing so customers can verify the request came from you
Retry with exponential backoff, jitter, a max attempt count
A circuit breaker so flaky endpoints don't cost you compute
A delivery log with replay for the "we never got that event" support ticket
A subscription model with rotatable secrets, event filters, active/inactive state

It's two weeks of work, plus ongoing maintenance. This post shows how to skip all of it.

The whole thing, in one SDK call

import { CentraliSDK, RecordEvents } from '@centrali-io/centrali-sdk';

const sub = await centrali.webhookSubscriptions.create({
  name: 'customer-acme-order-events',
  url: 'https://customer-acme.example.com/webhooks',
  events: [RecordEvents.CREATED, RecordEvents.UPDATED],
  recordSlugs: ['orders'],
});

// `secret` is returned on create only — copy it now, reads omit it.
console.log('Signing secret:', sub.data.secret!);

That's the whole setup. HMAC signing, retry, circuit breaker, delivery log, replay — all behind that one call. The rest of this post explains what just got handled for you, and shows how to wire up the customer side.

What you'd build yourself (and won't have to)

Before the tutorial, the honest version of what ships with a production-ready webhook system:

An outbound queue. You can't block the user's API request on an HTTPS call to a customer server. Something has to pull from a queue (Redis, SQS, BullMQ) and dispatch asynchronously.
HMAC signing. Sign the raw body with the subscription's secret, attach as a header. Secrets must be rotatable and scoped per subscription.
Retry with backoff. When a delivery fails (5xx or timeout), retry — but not immediately, and not forever. Exponential backoff is the baseline. Most teams get this subtly wrong: no jitter, too many attempts, too aggressive early.
Circuit breaker. When a customer's endpoint has been failing for minutes, stop attempting. Resume when it's healthy. Otherwise you waste compute on doomed requests and compound the outage.
Delivery log. Every attempt: HTTP status, response body, error, timestamp. This is the contract with support. When a customer asks "did you send it?", the log is the only answer that matters.
Manual replay. Customer deploys a fix, wants to catch up on the last hour. They need a replay endpoint. It shouldn't duplicate into your retry queue.
A subscription model. Customers create subscriptions, scoped to events and record types. Activate/deactivate. Rotate the secret without losing history.

Each item is a day of work. Together they're a sprint. Maintained well, they're an ongoing tax on your platform team.

What Centrali gives you

One line each, mapped to the list above:

Outbound queue: built in, no worker to deploy. Dispatch happens on record changes automatically.
HMAC signing: SHA-256 over the raw body, base64-encoded, header is X-Signature. Secret is whsec_…, auto-generated per subscription, rotatable.
Retry with backoff: 5 attempts over ~40 minutes — delays of 30s, 2m, 10m, 30m between attempts.
Circuit breaker: per-URL, opens when an endpoint is consistently failing, resets after a cool-down. Flaky endpoints stop costing you compute.
Delivery log: every attempt stored — HTTP status, error, payload, response body — visible in the console and queryable via API.
Manual replay: one endpoint — POST /webhook-subscriptions/deliveries/{id}/retry. New delivery is linked to the original via replayedFrom.
Subscription model: collection-scoped (via recordSlugs), event-type-filtered (record_created, record_updated, record_deleted), active/inactive, rotatable secret.

Tutorial: ship an outbound webhook in 5 minutes

The demo: a SaaS that tracks orders. When an order is created or updated, subscribed customers get a webhook.

Step 1: Create a collection

If you don't have one already, create an orders collection in the Centrali console. Any collection works — Centrali emits record events for every collection in the workspace.

Step 2: Subscribe a customer endpoint

You already saw the subscribe call at the top of the post. The response wraps the subscription under sub.data — the two fields that matter:

sub.data.id — subscription ID for updates and delivery queries
sub.data.secret — signing secret, returned once on create. Save it and hand it to your customer so they can verify incoming requests. If lost, rotate in the console: old-secret deliveries stay in the log, new deliveries use the new secret.

The console view shows the subscription with URL, event filters, a masked rotatable secret, signature header, and algorithm:

Prefer raw HTTP? Same shape over REST — POST /data/workspace/{your-workspace}/api/v1/webhook-subscriptions with a bearer token and a body matching the SDK call. Translating fetch or any HTTP client is one-to-one.

Step 3: Trigger an event

Any record change in the orders collection now fans out to subscribed endpoints. Create an order:

await centrali.createRecord('orders', {
  orderNumber: 'ORD-1045',
  customerEmail: 'pia@terradome.studio',
  total: 210,
  currency: 'USD',
  status: 'pending',
  itemCount: 3,
});

Centrali dispatches a POST to the subscribed URL within seconds. The request body looks like this:

{
  "event": "record_created",
  "workspaceSlug": "demo",
  "recordSlug": "orders",
  "recordId": "7d5a87d5-b10c-48bb-85d8-c42dbdaab417",
  "data": {
    "orderNumber": "ORD-1045",
    "customerEmail": "pia@terradome.studio",
    "total": 210,
    "currency": "USD",
    "status": "pending",
    "itemCount": 3,
    "placedAt": "2026-04-22T04:59:00Z"
  },
  "timestamp": "2026-04-22T04:59:02Z"
}

And the headers include the HMAC signature:

X-Signature: xXyHjYrTLS0bKh9qypUv8U5fj5UwBpIn2u0loyEoSQg=
Content-Type: application/json
User-Agent: Centrali-Webhooks/1.0

Step 4: Verify the signature on the customer side

The signature is HMAC-SHA256(signingSecret, rawBody), base64-encoded. The critical word is raw: compute it over the exact bytes you received, before any JSON parsing or middleware touches them.

Here's an Express.js handler that does it right:

import express from 'express';
import crypto from 'crypto';

const app = express();
const WEBHOOK_SECRET = process.env.CENTRALI_WEBHOOK_SECRET;

// Use raw body middleware for the webhook route only
app.post(
  '/webhooks/centrali',
  express.raw({ type: 'application/json' }),
  (req, res) => {
    const signature = req.get('X-Signature');
    if (!signature) return res.status(400).send('missing signature');

    const expected = crypto
      .createHmac('sha256', WEBHOOK_SECRET)
      .update(req.body) // req.body is a Buffer of the raw bytes
      .digest('base64');

    const valid = crypto.timingSafeEqual(
      Buffer.from(signature),
      Buffer.from(expected)
    );

    if (!valid) return res.status(401).send('invalid signature');

    const event = JSON.parse(req.body.toString('utf8'));
    console.log('got event:', event.event, event.recordId);

    // Do work, then 2xx to acknowledge
    res.status(200).send('ok');
  }
);

The two gotchas that trip up every first implementation:

Parse after verification. If you let express.json() touch the request first, the raw bytes are gone and the signature won't match. Use express.raw() for this route only.
Constant-time comparison. === leaks timing information. Use crypto.timingSafeEqual or your language's equivalent.

Normally you'd be writing the signing code too — on your server. Here your server doesn't ship webhook code at all. The only HMAC work is on the customer's end, which is where it belongs.

What happens when the customer's endpoint is down

The honest failure mode is what sells the feature. Create a second subscription pointed at a deliberately broken endpoint:

await centrali.webhookSubscriptions.create({
  name: 'customer-globex-order-events',
  url: 'https://httpbin.org/status/500',
  events: [RecordEvents.CREATED, RecordEvents.UPDATED],
  recordSlugs: ['orders'],
});

Trigger any order event and watch the delivery log. The first attempt fails with HTTP 500. The next four attempts happen at +30s, +2m, +10m, +30m. The log stays visible the whole time, with live nextAttemptAt and attemptCount values:

After the fifth attempt, the delivery's status flips to failed and the error is preserved:

No retry code in your app. No job queue. No alerts you wired up and forgot about. Just a log you point support at when someone asks "did it send?".

Replay a failed delivery once the endpoint is healthy

The customer fixes their endpoint. They want the missed events. Replay any failed delivery by ID:

await centrali.webhookSubscriptions.deliveries.retry(deliveryId);

A new delivery is created, pointed at the current subscription URL. The new delivery's detail view shows the original delivery ID under replayedFrom — you always know where a replay came from:

If replay was the entire story, you'd still need a queue. But combined with automatic retry plus the delivery log, the customer flow becomes:

Customer endpoint goes down.
Centrali tries for ~40 minutes, then gives up (logged).
Customer fixes their endpoint.
Customer (or you, from their support request) hits the replay endpoint once.
Back to normal — no lost events.

What's in the subscription model

If you've used Svix or Hookdeck, this shape will feel familiar:

Field	Purpose
`name`	Display name — usually the customer's name + event scope
`url`	HTTPS endpoint that receives deliveries
`events`	Event types to subscribe to — `record_created`, `record_updated`, `record_deleted`
`recordSlugs`	Collection filter — deliver only for these record slugs
`status`	`active` or `inactive` — pause without deleting
`signingSecret`	Shared secret for HMAC signing (auto-generated, rotatable)
`signatureHeader`	Header name for the signature (default: `X-Signature`)
`algorithm`	HMAC algorithm (default: `sha256`)
`encoding`	Signature encoding (default: `base64`)

One subscription per customer-per-scope. Rotating the secret doesn't lose history — existing deliveries in the log remain readable, future deliveries use the new secret.

When you should still build it yourself

If webhooks are core to your product — you're Zapier, or Segment, or you're Svix — you need more than what's in a backend platform. Per-customer delivery portals, detailed per-endpoint SLAs, webhook-as-a-product pricing, platform-wide rate budgets. Those companies exist for a reason and the category is real.

If webhooks are a feature of your product — one of many things your API does, and your customers want them — you don't need dedicated webhook infrastructure. You need the seven things above, and you need them to work without turning into a team's full-time job.

That's what the platform you're already using gives you.

Follow along: Create a free workspace and subscribe your first endpoint in 5 minutes. No deployment required.

What Is Record TTL? Database Time-to-Live Explained

Mary Olowu — Tue, 28 Apr 2026 18:22:25 +0000

Cross-posted from the Centrali blog. The canonical version with code highlighting and updates lives there.

TL;DR: Record TTL (time-to-live) is a database feature that automatically deletes records once they expire. You set an expiration time on a record — by duration ("delete in 1 hour") or by timestamp ("delete on March 1") — and the database removes it without a cron job. This is database TTL; it's the same idea as DNS TTL but applied to rows in a table instead of cached DNS lookups.

A note before we go further: if you searched for "TTL" and ended up here looking for DNS TTL (how long a DNS resolver caches an A/AAAA/CNAME record), this isn't that post — try Cloudflare's DNS TTL reference. This post is about record TTL in databases: making rows in your data store auto-delete on a schedule.

What Is Record TTL?

Record TTL is a per-record expiration time. The database tracks an expiresAt timestamp on the record (either set explicitly or computed from a duration), and once that timestamp passes:

The record disappears from query results immediately (read-time filtering).
A background sweep deletes it from storage permanently.

The two writes you make as a developer are:

ttlSeconds — a duration. "Delete this record 3,600 seconds from now." The database calculates the absolute expiresAt for you.
expiresAt — an absolute timestamp. "Delete this record at 2026-09-01T00:00:00Z."

Both end up storing the same field. Use ttlSeconds when the deadline is relative ("expire 24 hours after creation"); use expiresAt when the deadline is fixed ("expire on the sale end date").

How TTL Works (Mechanically)

Three things happen between "you wrote a TTL" and "the record is gone":

Write time — you create or update a record with ttlSeconds or expiresAt. The database stores the absolute expiration timestamp on the record.
Read time — every query is implicitly filtered against now(). Records past their expiresAt are excluded from results, even if they haven't been physically deleted yet.
Sweep time — a background job (every few minutes, depending on the database) finds expired records and deletes them. Some systems also publish an event ("record.expired") so your app can react before the row is gone.

The key property: expired records become invisible to your application instantly, even if the on-disk delete lags by minutes. You don't need to filter WHERE expiresAt > now() in every query — the database does it for you.

When to Use Record TTL

TTL is the right tool whenever you're tempted to write a "cleanup script that runs every night." Common cases:

Session tokens — expire after 24 hours of inactivity, or 30 days from creation.
Verification codes — one-time codes for email verification, magic links, password reset. Expire in 15 minutes.
Promo codes and flash deals — auto-disable when the deadline hits (or the flash window closes).
Draft content — autosave drafts that should evaporate after N days unless promoted to a published post.
Rate-limit windows — track requests-per-minute by storing a record per request with a 60-second TTL.
Audit logs with retention rules — "delete after 90 days" without writing the cleanup job yourself.
Cache-like records — when you need durable storage with cache-like eviction.

The negative test: TTL is the wrong tool when you need soft expiration — i.e., the record should be flagged as expired but kept around for analytics or recovery. For that, use a status field (status: 'archived') and filter explicitly. TTL means gone.

Default TTL vs. Per-Record TTL

Most databases that support record TTL let you set it at two levels:

Default TTL on the collection (or table) — every new record auto-inherits the duration. Set this for collections that are always time-bounded (sessions, verification codes).
Per-record TTL — override the default (or set TTL on a record in a non-TTL collection). Set this for one-off cases — flash promos in a long-lived "Promotions" table, for example.

A reasonable mental model: default TTL is for the table's intent; per-record TTL is for the exception.

Database TTL vs. DNS TTL

Same name, different concept. They share the underlying idea — "this thing is valid for N seconds, then forget it" — but they apply to different layers:

	DNS TTL	Database (record) TTL
What expires	A DNS record cached at a resolver	A row stored in your database
Who enforces it	DNS resolvers worldwide	Your database server
Typical duration	Seconds to hours	Minutes to months
Tunable per-record?	Yes (per DNS record)	Yes (per row, if the DB supports it)
What "expired" means	Resolver re-fetches from authoritative server	Row is hidden from queries and eventually deleted

If you're in the DNS world, TTL is about cache freshness. In the database world, TTL is about automatic cleanup. The mechanics aren't connected — your A-record TTL has nothing to do with your sessions table TTL.

Implementing Record TTL

Most managed databases now offer some form of record TTL: MongoDB has expireAfterSeconds indexes; DynamoDB has TTL attributes; Redis has EXPIRE. The exact API differs, but the shape is the same: a field on the record (or an index on a field) tells the database when to delete.

In Centrali, record TTL is built into the storage layer. You set ttlSeconds or expiresAt when creating a record, or set a default at the collection level:

import { CentraliSDK } from '@centrali-io/centrali-sdk';

const centrali = new CentraliSDK({
  workspaceId: 'my-workspace',
  clientId: process.env.CENTRALI_CLIENT_ID,
  clientSecret: process.env.CENTRALI_CLIENT_SECRET,
});

// Per-record TTL: this verification code expires in 15 minutes
await centrali.createRecord('VerificationCodes', {
  userId: 'user-123',
  code: '482910',
}, { ttlSeconds: 900 });

For a step-by-step walkthrough — sessions with sliding expiration, promo codes with fixed deadlines, draft content with TTL clearing on publish — see the companion post: How to Auto-Expire Records with Centrali TTL. Full reference lives in the Record TTL docs.

Centrali sits in a broader category — a backend for ingesting third-party webhooks, storing them as data, and sending your own webhooks and workflows. Record TTL is one feature inside the storage layer; if you're working with stored Stripe webhook events or schemaless data, the same TTL rules apply to those records.

Common Questions

Does TTL delete data immediately when it expires?
Records become invisible to queries the instant expiresAt passes. Physical deletion happens on a background sweep, typically within a few minutes. Don't rely on instant disk deletion for security-sensitive data — use a separate purge if you need it gone now.

Can I extend a TTL after the record is created?
Yes — update the record with a new ttlSeconds or expiresAt. This is how "sliding expiration" works for sessions: every authenticated request resets the TTL.

Can I remove a TTL after setting one?
Yes — most TTL implementations support clearing the expiration so the record becomes permanent. In Centrali, pass { clearTtl: true } on the update.

Is TTL the same as data retention policy?
TTL is a mechanism for retention. A retention policy is the rule ("keep audit logs for 90 days"); TTL is one way to enforce it. Other ways: scheduled jobs, archival to cold storage, manual purges.

What's the smallest practical TTL?
Depends on the database, but seconds-level TTL is common. Sub-second TTL usually doesn't make sense — by the time the write replicates, the record may already be expired.

Summary

Record TTL is the database equivalent of "set it and forget it" cleanup: assign an expiration to a record, and the database handles the rest. Use it for any data that's intrinsically time-bounded — sessions, codes, promos, drafts, rate-limit windows. Don't confuse it with DNS TTL; same name, different layer.

If you want to see TTL in action with concrete code, the auto-expire records guide walks through three full use cases.

Originally published on centrali.io/blog/what-is-record-ttl. Centrali is the backend for webhooks in and out — ingest third-party webhooks, store them as data, and send your own workflows from one SDK.

How to Test Stripe Webhooks Locally (Stripe CLI + Replay + Logs)

Mary Olowu — Wed, 22 Apr 2026 07:43:19 +0000

Most Stripe webhook bugs are not business logic bugs. They are reproducibility bugs. If you can't replay the exact event path in under 30 seconds, debugging takes hours instead of minutes — because every attempt involves refreshing the Stripe Dashboard, re-triggering a test, and squinting at logs to figure out whether your handler ran at all.

This post walks through the local loop that makes this painless: forward → trigger → replay → inspect. Four steps, one terminal window, no guessing.

The loop, in full

# Terminal 1 — forward Stripe events to your local handler
stripe listen --forward-to "http://localhost:3000/api/stripe-webhook"

# Terminal 2 — trigger real Stripe test events
stripe trigger payment_intent.succeeded
stripe trigger charge.failed
stripe trigger invoice.payment_failed

# When something fails, replay the exact event
stripe events resend evt_1NfP6Q2eZvKYlo2CsKT4a5oS

That is the whole loop. Everything below is how to make it reliable.

Step 1 — Give your dev webhook its own path

Don't forward Stripe events to your production webhook path. Use a dedicated dev path:

stripe listen --forward-to "http://localhost:3000/api/stripe-webhook-dev"

Why separate? Because you want to test with lax validation (no signature verification, verbose logging) without loosening your production handler. Keep two paths:

/api/stripe-webhook — production. Strict signature verification, minimal logs.
/api/stripe-webhook-dev — dev only. Signature check optional, logs every field.

When stripe listen starts, it prints a signing secret:

> Ready! Your webhook signing secret is whsec_abc123...

Copy that into your dev environment variable (STRIPE_WEBHOOK_SECRET_DEV). This is NOT the same as the secret from your Stripe Dashboard — the CLI generates its own. This trips up everyone the first time.

Step 2 — Trigger real events, not made-up payloads

Do not hand-craft JSON payloads. Stripe's trigger command sends a real event through your account's test data, which means you're testing against payloads that match production exactly.

# Core payment flows
stripe trigger payment_intent.succeeded
stripe trigger charge.succeeded
stripe trigger charge.failed

# Subscription lifecycle
stripe trigger customer.subscription.created
stripe trigger customer.subscription.updated
stripe trigger customer.subscription.deleted

# Invoice / billing
stripe trigger invoice.payment_succeeded
stripe trigger invoice.payment_failed

Each trigger writes a real event to your Stripe test account. That means every event has a real id (starts with evt_) that you can replay later.

Run all the events your handler cares about at least once. Anything you haven't triggered locally is a surprise waiting in production.

Step 3 — Replay the exact event, on demand

This is the step most people skip, and it's where debugging speed compounds. When a test fails, you can replay the exact same event by ID:

stripe events resend evt_1NfP6Q2eZvKYlo2CsKT4a5oS

Same payload. Same signature. Same timestamp. Your handler sees a byte-for-byte identical request.

This is gold for two reasons:

Idempotency testing. Your handler should be safe to call with the same event ID twice. Replay it five times in a row and confirm you create one record, not five. If you create five, you have a bug.
Deterministic debugging. When something fails at 2am, you can add a console.log, restart your server, and replay the same event. No hunting for a new trigger, no hoping you can reproduce the path.

Step 4 — Validate via logs, not hope

For every event, verify:

✓ Your handler returned 200 (Stripe will retry otherwise)
✓ The event ID was logged
✓ A record was created (first time)
✓ A replay was skipped (second time — idempotency)
✓ Unknown event types no-op safely (don't throw)

A minimal handler that makes this visible:

export default async function handler(req, res) {
  const event = verifySignature(req); // or skip on dev path

  console.log(`[stripe] ${event.type} ${event.id}`);

  const existing = await findEvent(event.id);
  if (existing) {
    console.log(`[stripe] skipped duplicate ${event.id}`);
    return res.json({ received: true, skipped: true });
  }

  switch (event.type) {
    case 'payment_intent.succeeded':
      await handlePaymentSucceeded(event.data.object);
      break;
    case 'charge.failed':
      await handleChargeFailed(event.data.object);
      break;
    default:
      console.log(`[stripe] no-op for ${event.type}`);
  }

  await recordEvent(event);
  res.json({ received: true });
}

Three rules this enforces:

Log the event ID on every call. When something goes wrong, the event ID is the only key that connects Stripe's dashboard to your logs.
Return 200 even for no-ops. Stripe retries non-200 responses. A throw on an unknown event type will get retried for 3 days and fill up your logs.
Make duplicate detection visible. When you replay for testing, you want to SEE that the skip branch fired.

Pre-production checklist

Before you switch Stripe from your CLI forwarder to your real endpoint:

[ ] Every event type you care about has been triggered locally at least once
[ ] Each one has been replayed and the idempotency branch ran
[ ] At least one unknown event type was sent — handler returned 200, did not throw
[ ] Signature verification works in prod mode with the real Dashboard secret (not the CLI secret)
[ ] Handler returns 200 in under 5 seconds for all event types (Stripe times out at 30s but backs off aggressively if you're slow)
[ ] Logs include event ID on every line relevant to the event

What this costs

Nothing. The Stripe CLI is free. stripe trigger uses your test mode data. stripe events resend uses events you already generated. You don't need a tunnel service (ngrok, localtunnel) — stripe listen does the forwarding itself.

What to pair this with

If you want stored event history you can query later (replay a 2-week-old event, audit a customer's event sequence, etc.), you need something between Stripe and your handler that logs every event permanently. Stripe's own Events API only goes back 30 days and can't filter by fields you care about.

Centrali's webhook triggers do this out of the box — every inbound event is stored in a collection you can query later. But the testing loop above works with any handler, framework, or platform. The important part is the loop.

If this was useful, I write more about webhook reliability and Stripe integration patterns. Follow me for more.

Stop Writing Custom Scrapers: Index Static Content into Meilisearch with One Config

Mary Olowu — Wed, 22 Apr 2026 07:42:56 +0000

TL;DR — content-mill is an open-source CLI and library that reads static content — MkDocs sites, markdown directories, JSON files, HTML pages — and indexes it into Meilisearch, driven by a YAML config. You define the document shape; it handles extraction, templating, chunking, and atomic zero-downtime re-indexing. You still tune templates and debug extraction for your own content — that part's on you — but you stop maintaining bespoke scraper code.
npm install @centrali-io/content-mill

If you've ever tried to make your docs, blog posts, or changelogs searchable with Meilisearch, you know the drill: write a custom scraper, parse the content, transform it into the right shape, push it to an index, and hope you don't break search during re-indexing.

I got tired of writing that glue code for every project, so I built content-mill — a CLI and library that indexes static content into Meilisearch, driven by a YAML config.

The problem

Meilisearch is fantastic for search, but getting your content into it is surprisingly manual. Every docs site, every changelog, every collection of markdown files needs its own extraction pipeline. And if you want zero-downtime re-indexing? That's more code on top.

Most existing solutions are either tightly coupled to a specific framework (like DocSearch for Algolia) or expect you to run a full crawler. Lighter-weight options exist — usually ad-hoc scripts people write once per project — but nothing I could find that's reusable across source types and explicit about document shape.

What content-mill does

You describe your content sources and the document shape you want in a YAML config:

meili:
  host: http://localhost:7700
  apiKey: ${MEILI_MASTER_KEY}

sources:
  - name: docs
    type: mkdocs
    config: ./mkdocs.yml
    index: docs
    document:
      primaryKey: id
      fields:
        id: "{{ slug }}"
        title: "{{ heading }}"
        content: "{{ body }}"
        section: "{{ nav_section }}"
        url: "{{ path }}"
        type: "docs"
      searchableAttributes: [title, content]
      filterableAttributes: [section, type]

Then run:

npx @centrali-io/content-mill index --config content-mill.yml

Once the config matches your content, re-running is a single command. You'll still spend time tuning templates and sanity-checking extraction (use --dry-run for that) — but you're not maintaining scraper code anymore. content-mill handles extraction, templating, and atomic index swapping, so search never goes down during re-indexing.

Four source types, one interface

content-mill ships with adapters for the content formats you're most likely already using:

mkdocs — Reads your mkdocs.yml, follows the nav tree, and parses each markdown page. You get nav_section context so you know which part of the docs each page belongs to.
markdown-dir — Recursively reads .md files from a directory. Supports YAML frontmatter, so you can pull version numbers, dates, or any metadata into your search index. Great for changelogs and blog posts.
json — Reads a JSON array (or directory of JSON files). Every key in each object becomes a template variable. Perfect for structured data you already have lying around.
html — Reads .html files, strips scripts/styles/nav/footer, and gives you clean text. Useful for indexing a built static site.

Templating: you control the document shape

The key design decision is that you define what your Meilisearch documents look like. Source adapters extract raw variables (slug, heading, body, path, frontmatter.*, etc.), and you map them to fields using {{ template }} syntax:

fields:
  id: "{{ slug }}-{{ chunk_index }}"
  title: "{{ chunk_heading }}"
  content: "{{ chunk_body }}"
  excerpt: "{{ body | truncate(200) }}"
  url: "{{ path }}#{{ chunk_heading | slugify }}"

Filters like truncate, slugify, lower, upper, and strip_md can be chained with pipes. This means you're not locked into someone else's schema — your search index looks exactly the way your frontend expects.

Chunking for granular results

Whole-page results are often too broad for docs search. content-mill can split pages by heading level:

chunking:
  strategy: heading
  level: 2

This turns one long page into multiple documents — one per ## section — each with its own chunk_heading, chunk_body, and chunk_index. Your search results can now link directly to the relevant section instead of dumping users at the top of a page.

Zero-downtime re-indexing

Every indexing run uses Meilisearch's index swap:

Documents go into a temp index (docs_tmp)
Atomic swap with the live index (docs)
Old index gets cleaned up

If something fails mid-way, your live index is untouched. No maintenance windows needed.

CI/CD in two lines

# GitHub Actions
- name: Index docs
  env:
    MEILI_MASTER_KEY: ${{ secrets.MEILI_MASTER_KEY }}
  run: npx @centrali-io/content-mill index --config content-mill.yml

Hook this into your release pipeline and your search index stays in sync with every deploy.

Use as a library

Don't need the CLI? Import it directly:

import { loadConfig, indexAll } from '@centrali-io/content-mill';

const config = loadConfig('./content-mill.yml');
await indexAll(config, { dryRun: false });

Or build the config object in code if you prefer programmatic control.

Why not docs-scraper, DocSearch, or a custom crawler?

docs-scraper (the Meilisearch-native option) is a Scrapy-based web crawler. Works well for live sites, heavy for "I already have markdown in a repo."
Algolia DocSearch is excellent, but framework-specific and indexes into Algolia — not useful if you've chosen Meilisearch.
Custom scrapers work fine for one project. Painful when you have three of them to maintain across different repos.

content-mill is intentionally narrow: static content in, Meilisearch out, config-driven shape in between. If you're not already on Meilisearch, use something else.

Getting started

npm install @centrali-io/content-mill

Create a content-mill.yml with your Meilisearch connection and source definitions
Run with --dry-run first to preview the extracted documents
Run for real and check your Meilisearch dashboard

The full config reference and source type examples are in the README on GitHub.

content-mill is MIT-licensed and open source. If you use Meilisearch and have static content to index, try it — and if your source type isn't covered (AsciiDoc, RST, Notion export, whatever), open an issue and I'll look at adding an adapter.

Stop Writing Custom Scrapers: Index Any Static Content into Meilisearch with One Config File

Mary Olowu — Wed, 25 Mar 2026 05:16:16 +0000

I got tired of writing that glue code for every project, so I built content-mill — a CLI and library that indexes static content into Meilisearch from a single YAML config.

The Problem

Most existing solutions are either tightly coupled to a specific framework (like DocSearch for Algolia) or require you to write a full crawler. If you just have some markdown files and a Meilisearch instance, there's nothing lightweight that bridges the gap.

What content-mill Does

You describe your content sources and the document shape you want in a YAML config:

meili:
  host: http://localhost:7700
  apiKey: ${MEILI_MASTER_KEY}

sources:
  - name: docs
    type: mkdocs
    config: ./mkdocs.yml
    index: docs
    document:
      primaryKey: id
      fields:
        id: "{{ slug }}"
        title: "{{ heading }}"
        content: "{{ body }}"
        section: "{{ nav_section }}"
        url: "{{ path }}"
        type: "docs"
      searchableAttributes: [title, content]
      filterableAttributes: [section, type]

Then run:

npx @centrali-io/content-mill index --config content-mill.yml

That's it. content-mill reads your sources, extracts content, applies your field templates, and pushes everything to Meilisearch with atomic index swapping (so search never goes down during re-indexing).

Four Source Types, One Interface

content-mill ships with adapters for the content formats you're most likely already using:

mkdocs — Reads your mkdocs.yml, follows the nav tree, and parses each markdown page. You get nav_section context so you know which part of the docs each page belongs to.

markdown-dir — Recursively reads .md files from a directory. Supports YAML frontmatter, so you can pull version numbers, dates, or any metadata into your search index. Great for changelogs and blog posts.

json — Reads a JSON array (or directory of JSON files). Every key in each object becomes a template variable. Perfect for structured data you already have lying around.

html — Reads .html files, strips scripts/styles/nav/footer, and gives you clean text. Useful for indexing a built static site.

Templating: You Control the Document Shape

fields:
  id: "{{ slug }}-{{ chunk_index }}"
  title: "{{ chunk_heading }}"
  content: "{{ chunk_body }}"
  excerpt: "{{ body | truncate(200) }}"
  url: "{{ path }}#{{ chunk_heading | slugify }}"

Chunking for Granular Results

Whole-page results are often too broad for docs search. content-mill can split pages by heading level:

chunking:
  strategy: heading
  level: 2

Zero-Downtime Re-indexing

Every indexing run uses Meilisearch's index swap:

Documents go into a temp index (docs_tmp)
Atomic swap with the live index (docs)
Old index gets cleaned up

If something fails mid-way, your live index is untouched. No maintenance windows needed.

CI/CD in Two Lines

# GitHub Actions
- name: Index docs
  env:
    MEILI_MASTER_KEY: ${{ secrets.MEILI_MASTER_KEY }}
  run: npx @centrali-io/content-mill index --config content-mill.yml

Hook this into your release pipeline and your search index stays in sync with every deploy.

Use as a Library

Don't need the CLI? Import it directly:

import { loadConfig, indexAll } from '@centrali-io/content-mill';

const config = loadConfig('./content-mill.yml');
await indexAll(config, { dryRun: false });

Or build the config object in code if you prefer programmatic control.

Getting Started

npm install @centrali-io/content-mill

Create a content-mill.yml with your Meilisearch connection and source definitions
Run with --dry-run first to preview the extracted documents
Run for real and check your Meilisearch dashboard

The full config reference and source type examples are in the README on GitHub.

content-mill is MIT licensed and open source. If you're using Meilisearch and have static content to index, I'd love to hear how it works for your use case. Issues and PRs welcome on GitHub.

Tags: #meilisearch #search #typescript #opensource

Exponential vs Linear: How to Tell If Your Event-Driven Trigger Is Looping

Mary Olowu — Sun, 15 Mar 2026 23:46:07 +0000

Exponential vs Linear: How to Tell If Your Event-Driven Trigger Is Looping

The Core Idea

When you're building rate limits for event-driven triggers, you face a fundamental problem: how do you set a threshold that catches loops without blocking legitimate high-volume workloads?

The answer is that loops and legitimate traffic have fundamentally different growth characteristics:

Legitimate triggers scale linearly with user actions.

1 user creates 1 order → 1 trigger execution
50 users create 50 orders per minute → 50 trigger executions per minute
The ratio is always 1:1. Trigger executions track user actions.

Recursive loops scale exponentially from a single user action.

1 user creates 1 record → trigger fires → function creates another record → trigger fires again
After 10 seconds: 100+ executions
After 60 seconds: 700+ executions
All from 1 user action. The trigger is its own input.

This isn't a subtle distinction. It's the difference between a line and an exponential curve. And it means your rate limit doesn't need to be clever — it just needs to sit in the massive gap between the two curves.

Why This Matters for Rate Limit Design

A rate limit of 100 executions per 60 seconds:

Never blocks legitimate traffic. Even a high-volume e-commerce system processing 80 orders per minute sits under the limit.
Always catches loops. A recursive loop hits 100 executions in under 8 seconds.

The gap between "highest legitimate volume" and "slowest possible loop" is enormous. You don't need machine learning or anomaly detection. You just need basic arithmetic.

The Math

A recursive trigger loop doubles (at minimum) with each iteration. If one trigger execution creates one record, and that record fires one trigger:

Time	Executions (cumulative)
Iteration 1	1
Iteration 2	2
Iteration 3	4
Iteration 10	1,024
Iteration 16	65,536

Even with network latency and compute overhead slowing each iteration to 100ms, you hit 100 executions in ~7 seconds. With faster execution (10ms per iteration), you hit 100 in under a second.

Meanwhile, the highest legitimate trigger volume we've seen across our platform is ~80 executions per minute per trigger — and that's a busy e-commerce workspace during a flash sale.

The gap is 10x-100x. Your rate limit has a lot of room.

What About Burst Traffic?

The natural objection: "What about a bulk import? A user imports 500 records at once, and each fires a trigger."

This is a valid concern but a different problem:

Bulk imports via API publish a single aggregate event (records_bulk_created), not 500 individual events. Event-driven triggers don't match on the aggregate event, so they don't fire at all.
Batch operations from compute functions do publish individual events. But even 500 trigger executions from a batch operation is a one-time burst, not a sustained loop. If your rate limit window is 60 seconds, the burst registers once. A loop registers continuously.
If batch-triggered functions need to fire triggers, the rate limit should be configurable per-trigger. Default 100/60s works for 99% of cases. The 1% that needs more can raise it.

Implementing the Test

The simplest implementation is a Redis counter with a TTL:

async function isWithinRateLimit(triggerId: string): Promise<boolean> {
  const key = `trigger_rate:${triggerId}`;
  const count = await redis.incr(key);
  if (count === 1) await redis.expire(key, 60);
  return count <= 100;
}

That's it. Six lines. The INCR is atomic (no race conditions across instances), the EXPIRE handles cleanup, and the threshold separates linear from exponential with a 10x margin.

Beyond Rate Limiting

Rate limiting is the safety net, not the whole solution. For a complete defense:

Block obvious loops at configuration time. When a user creates a trigger on record_created for collection X, and the function calls api.createRecord('X', ...), reject it with a clear error. This is prevention, not detection.
Track causality at runtime. Propagate a sourceTriggerId through event chains so you can identify self-loops without waiting for the rate limit to trip. The user gets a "recursive loop detected" message instead of a vague "rate limit exceeded."
Rate limit as the catch-all. For cross-trigger chains (A→B→A) and exotic patterns that bypass the first two layers.

We wrote a detailed post about implementing all three layers: How We Stopped Recursive Trigger Loops From Melting Our Compute Fleet.

The Takeaway

If your platform has event-driven triggers, ask yourself: can a trigger's output become its own input? If yes, you need loop protection. And the simplest, most reliable loop protection is a rate limit set in the gap between linear user-driven traffic and exponential recursive behavior.

That gap is enormous. Use it.

Building event-driven infrastructure? We'd love to hear about your trigger architecture challenges. Reach out on [Twitter/X] @centraliio or drop a comment.

DEV Community: Mary Olowu

I Renamed a Hot Postgres Table Without Dropping a Request

The real failure mode

The shim

The part people miss: writes

The objection that mattered

What I tested

Why this beats expand/contract for a pure rename

When I would use this

When I would not

What the rollout looked like

The takeaway

LLMs Are Probabilistic. Your Workflow Shouldn't Be.

Why This Matters

Even the Model Vendors Are Telling You This

The Architectural Rule

The Boring Architecture That Wins

1. LLM as interpreter

2. Typed output contract

3. Deterministic validator

4. Workflow engine or state machine

5. Scoped tools

6. Tracing, logs, and evals

The Anti-Pattern

NIST Is Basically Handing You the Blueprint

A Good Mental Model

What I Would Build First

The Take

Sources

What an AI Agent's Memory Layer Actually Has to Store

AI Can Write the Code. It Still Forgets the Decisions That Matter.

I Stopped Using Claude Code as a Giant Prompt and Started Using It as Project Ops

TL;DR

The Problem With Default AI Usage on Ongoing Projects

The Structure I Ended Up With

1. CLAUDE.md Is for Rules, Not Everything

2. docs/maintainers/ Holds the Durable Context

3. Local JSON Memory Is Good Enough

4. Real Systems of Record Stay Real

The Commands Were the Biggest UX Upgrade

Where This Fits Relative to Spec Kit

Why This Was Especially Useful in a Monorepo

The Portable Part

What I Would Recommend If You Try This

Closing

Ingest Webhooks From Any Provider — GitHub as the Example

How GitHub Webhook Signatures Work

Step 1: Write the Store Function

Step 2: Create the HTTP Trigger

Configure Signature Verification

Step 3: Configure the Webhook in GitHub

Step 4: See Your Data

The Pattern Works for Any Provider

Query Programmatically

What's Next

Add Webhooks to Your SaaS in 10 Minutes (Without Queues or Retries)

The whole thing, in one SDK call

What you'd build yourself (and won't have to)

What Centrali gives you

Tutorial: ship an outbound webhook in 5 minutes

Step 1: Create a collection

Step 2: Subscribe a customer endpoint

Step 3: Trigger an event

Step 4: Verify the signature on the customer side

What happens when the customer's endpoint is down

Replay a failed delivery once the endpoint is healthy

What's in the subscription model

When you should still build it yourself

Related reading

What Is Record TTL? Database Time-to-Live Explained

What Is Record TTL?

How TTL Works (Mechanically)

When to Use Record TTL

Default TTL vs. Per-Record TTL

Database TTL vs. DNS TTL

Implementing Record TTL

Common Questions

Summary

How to Test Stripe Webhooks Locally (Stripe CLI + Replay + Logs)

The loop, in full

1. `CLAUDE.md` Is for Rules, Not Everything

2. `docs/maintainers/` Holds the Durable Context