Give every database a clear job

Adding another database is easy. Keeping two stores from quietly disagreeing about the same user, job, or entitlement is the harder part.

The useful question is not whether a product has one database or three. It is whether a developer can answer, for every important record: which system owns it, which systems copy it, and what happens when one store is unavailable?

Name the authoritative owner

Give each kind of data one authoritative home. Other systems can cache or project it for a specific purpose, but they should not become competing places to edit the same fact.

For example, a product might store login identity in an identity service, relational business records in PostgreSQL, and short-lived recovery snapshots in object or file storage. That arrangement is reasonable only when the boundaries are explicit. A snapshot should not accidentally become the source of truth for billing; an analytics copy should not become the place where a user changes account settings.

In PinLeads, Firebase owns account, team, and billing settings; PostgreSQL stores paid lead data and job history; JSON snapshots let active scraping work recover after a server restart. Each store has a defined responsibility rather than each being a second copy of everything.

Draw the write path

For each workflow, write down the order of writes and the point at which the user can consider the action accepted. If one request changes two stores, ask what happens if the first write succeeds and the second fails.

There is no free cross-database transaction. Depending on the product, a workflow can use an outbox, a durable job, a retryable state transition, or a compensating action. The important part is to persist enough intent to finish or explain the operation after a process stops. Do not hide a partial write behind a generic success response.

Treat copies as copies

If one store contains a projection of another, record where the projection came from and how it is refreshed. Define what happens when records are edited or deleted. A projection with no refresh or deletion rule becomes a second, stale product database.

Snapshots have a different purpose from long-term records. They can help restore in-flight work, but they need a clear retention window and a way to tell whether the saved state is still safe to resume. Recovery data should make a workflow recoverable, not silently override a newer user decision.

Design failure tests around boundaries

The most useful persistence tests stop the workflow between writes. Simulate a process restart after job state is saved, a database timeout after a billing change is accepted, and a retry after a client loses its response. Then verify that the system either completes the intended transition once or reports a state a person can act on.

Also test lifecycle questions that are easy to miss during feature work: can a user export or delete their data, can support trace a record to its source, and can a stale snapshot be discarded safely?

Add a store only for a reason

More stores can make a product clearer when their jobs differ. They also add credentials, backups, migrations, monitoring, and failure modes. Before adding one, identify the ownership boundary it creates and the operating work it costs.

The design goal is not to force every product into one database. It is to keep ownership visible enough that a failure, retry, or deletion has one understandable path through the system.