DEV Community: Aditya Pradhan

Database per Service: ownership, not isolation

Aditya Pradhan — Wed, 10 Jun 2026 18:42:46 +0000

Every microservices deck draws the same box: one database per service, labeled as a security boundary. That label is the assumption most teams copy. Database per Service pays off for a different reason.

The coupling you feel before the outage

Picture two product teams on one Postgres instance. Team A ships a column rename Friday afternoon. Team B's release does not go out until Monday because migration ordering became a meeting, not a merge.

Nobody got paged. The deploy queue stalled. That is what shared-schema coupling looks like in week two of "we are microservices now."

For a long time one database with many services was normal. Coordinated migration windows, shared release trains, one schema everyone negotiated. The diagram said microservices. The datastore said monolith.

Then the org splits into teams with different roadmaps. Same database. Different release trains. The pain shows up in deploy queues long before it shows up in an outage.

What Database per Service actually decouples

Database per Service is not isolation theater. It separates three things a shared database fuses together:

Schema ownership — who can change the tables, and who gets called when a migration fails.
Deployment cadence — how fast each team can ship schema changes without a committee.
Failure blast radius — how far a poison migration or lock contention fans out.

Each datastore is a bounded context contract. You are not drawing a security perimeter on a slide. You are deciding who can change orders.status without a three-team approval thread.

flowchart LR
  subgraph shared["Shared database (coupled)"]
    S1[Orders service] --> PG[(Postgres)]
    S2[Inventory service] --> PG
    S3[Billing service] --> PG
  end

  subgraph split["Database per Service (decoupled)"]
    O[Orders] --> DO[(orders_db)]
    I[Inventory] --> DI[(inventory_db)]
    B[Billing] --> DB[(billing_db)]
  end

What you trade away

Independence has a price. The weekly revenue report that used to be one query becomes a pipeline problem.

-- Works on a shared schema. Breaks when orders and inventory are separate databases.
SELECT o.id, i.sku, o.total
FROM orders o
JOIN inventory i ON o.sku = i.sku
WHERE o.created_at > now() - interval '7 days';

After the split, that join lives somewhere else:

An outbox stream into a warehouse.
A materialized view fed by CDC.
A saga with compensating steps instead of a cross-service transaction.

None of those is simpler than a join. They are simpler than four teams negotiating one migration order every sprint.

Cadence is the second win. Billing ships schema v3 while catalog stays on v1.

Blast radius is the third. A poison migration in one database does not lock tables in another.

When to split vs when to stay shared

Split databases when team boundaries and release independence matter more than cross-service transactions and ad-hoc reporting joins.

Keep one shared database when you are still one product, one release train, and analytics lives on relational joins you are not ready to rebuild as events.

If you copied the diagram but not the org structure, you pay the distributed-data tax without getting the ownership benefit.

Decision checklist

Before you draw separate database boxes on the next architecture review, ask:

Do different teams own different services with different roadmaps?
Has a shared migration already blocked someone's deploy?
Would a bad migration in Service A be acceptable if it took down Service B's tables?
Is your reporting workload built on cross-service SQL joins you cannot yet replace with events or a warehouse?

If 1 and 2 are yes and 3 is no, Database per Service is probably earning its keep. If you are still one team shipping one product, a shared database is often the honest choice until the org boundary catches up to the diagram.

Implementing Passkeys Beyond the Demo

Aditya Pradhan — Wed, 17 Dec 2025 09:24:40 +0000

We did not introduce passkeys to replace passwords. Passwords are still very much part of our system, especially as a fallback and for account recovery. The real problem we were trying to solve was repeated login friction.

For product reasons, we do not keep users logged in when the browser is closed. That meant even active users were entering their passwords far more often than they would expect. Over time, this showed up as friction rather than outright failure. People were not locked out, but they were annoyed. Login felt like work, especially on shared devices or short sessions.

Passkeys stood out because they reduced that friction without changing our core security posture. There was no need to introduce long-lived sessions or relax existing constraints. A biometric or platform authenticator prompt was faster than typing a password, even if it happened often. The goal was not passwordless accounts, but smoother re-authentication.

At a high level, passkeys are a way to authenticate users using device-bound credentials backed by public key cryptography. From a user perspective, they feel closer to unlocking a device than logging into a website. That distinction mattered more than the underlying standard.

What followed was less about implementing WebAuthn itself and more about fitting a new login primitive into a system that already had assumptions baked into it. Passkeys worked well in isolation. Making them coexist cleanly with passwords, recovery flows, and real user behaviour was where most of the complexity lived.

Passkeys at a High Level

At a conceptual level, passkeys are not complicated. Instead of proving identity by sending a shared secret like a password to the server, the browser uses a key pair that was created earlier and is tied to the user and the device. The private key never leaves the device. The server only stores a public key and asks the client to prove possession when needed.

From an implementation point of view, WebAuthn gives you two main flows. One for creating a credential and one for asserting it later during login. The browser mediates both, and the user experience is largely controlled by the platform, not your UI. That is both a strength and a constraint.

Passkeys are device-bound by default, sometimes synced across devices depending on the platform, and they depend heavily on browser and OS behaviour that your application does not control. That has implications for UX, support, and how you reason about account access.

Once we got past the conceptual simplicity, the gaps started to show. The demo flows worked fine. The real system, with real users and real constraints, was where things became more interesting.

Implementation Was Not the Hard Part

Once we committed to passkeys, the core implementation moved faster than expected. There are enough reference implementations available now to avoid guessing, and we leaned on Google’s example repository to validate the overall flow and API boundaries.

We also chose early on not to touch protocol-level details ourselves. Using simplewebauthn meant binary conversions, base64 handling, and request shaping were taken care of. That kept the passkey code small and isolated, and reduced the risk of subtle bugs that are hard to reason about later.

From a pure coding perspective, the passkey flows were simpler than our existing password flows. Fewer UI states and fewer opportunities for partial failure.

Reality Hit During Cross-Device Testing

The first real friction showed up when we tried to build confidence beyond a single setup. Passkeys are device-bound, which sounds manageable until you start testing across Macs, Windows machines, iPhones, and Android devices.

Browser differences added another layer. Chrome and Firefox did not always behave the same way on the same hardware. Mobile browsers introduced their own quirks around prompts and interruptions. Some combinations worked reliably, others failed intermittently, and not all failures were easy to reproduce.

Automated tests helped at the API layer, but they barely touched the actual user experience. Most confidence came from manual testing on real devices, which made iteration slower and raised the cost of regressions.

Error Handling Was Less Predictable Than Expected

Not all failures surfaced as explicit errors. In some cases, browser APIs would enter a pending state that neither resolved nor rejected for an extended period of time. From the user’s perspective, the login just appeared stuck.

We ended up implementing our own timeout mechanism around passkey operations. This was not part of the original plan, but it became necessary to keep the UI responsive and to provide a clear fallback to password-based login when something went wrong.

Once timeouts were in place, we could fail fast, surface meaningful feedback, and avoid trapping users in a broken flow.

Debugging in Production Required New Discipline

Supporting passkeys after rollout was harder than shipping them. Much of the execution path lives inside the browser and the operating system, which limits what you can directly observe.

When users reported issues, they often could not describe what failed beyond saying that the login did not work. Server-side errors alone were not enough to diagnose these cases.

To compensate, we added logging at every meaningful boundary in the passkey flow. Challenge creation, request dispatch, client response receipt, verification steps, and final resolution. Over time, these logs became essential for identifying platform-specific issues and spotting patterns across devices.

Looking back, the protocol was not the hard part. Making the system observable and debuggable across platforms was.

Closing Thoughts

Passkeys improved our login experience, but they did not simplify authentication as a whole. Passwords are still part of the system, and that is intentional. Treating passkeys as an additive flow rather than a replacement gave us flexibility during rollout and reduced risk when things went wrong.

After shipping passkeys, we saw roughly a 60 percent improvement in login efficiency. That number is directional and very much dependent on how you measure it, but it aligned with what we saw anecdotally. Fewer retries, faster re-authentication, and less visible frustration during login.

The main shift for the team was not technical complexity, but operational thinking. More of the flow lives in the browser and the OS, which means less control and fewer guarantees. Logging, timeouts, and conservative assumptions mattered more than protocol correctness.

Passkeys are worth considering if repeated authentication is a real source of friction in your product. They work best when integrated deliberately, with clear fallbacks and realistic expectations. Like most changes to core infrastructure, the gains come from careful integration, not from the technology alone.