One Membership Across Multiple Products: Architecture Thinking for Single Sign-On

When you build your first product's membership system, everyone works on instinct: sign-up, login, forgot-password, all in your own database, done in two weeks. The problem detonates when you launch a second product — the new product builds another membership system, the two user bases don't line up, the same person has two accounts and two passwords, and when marketing wants to send a notification, they first have to ask engineering "how do we merge these two lists?" We walked exactly this road ourselves: our team runs a brand storefront plus multiple app products, and we once fed a separate membership system for each product. Eventually we bit the bullet and extracted identity into a group-wide member center, with every product using single sign-on (SSO — one account logs into all services).

This article shares the three key architecture decisions from our experience. If your company has more than one digital product — or plans to — these are pitfalls worth thinking through before you start.

Decision one: a single identity source — member data has exactly one "truth"

The core principle in one sentence: only one place in the entire group may "own" members. We call it the identity center: registration, login, password changes, third-party login binding — all of it happens only there. Each product's own database no longer has a members table; it has only a lightweight mirror table storing the identifier issued by the identity center plus a display nickname, so the product's orders and records have something to relate to.

Why not let each product keep a full copy of member data and sync with each other? Because two-way sync is one of the hardest problems in distributed systems: if both sides can write, conflicts are inevitable; conflicts need arbitration; arbitration rules grow exceptions; and eventually you're feeding a sync program nobody dares touch. A single identity source cuts the problem off — only one place can write, everything else is a read-only mirror, and the architecture instantly becomes an order of magnitude simpler.

Decision two: data minimization — product databases never touch PII

The second decision is more counterintuitive: product databases are forbidden from storing email, phone, address, or password hashes — any personal data. When a product needs to display member details, it fetches them from the identity center via API in real time and never persists them.

Two benefits. For security: personal data is concentrated in one system, so protective resources can be concentrated too — and if some peripheral product gets breached one day, what leaks is identifiers and nicknames, not the whole group's phone numbers and addresses. For compliance: data protection law requires you to account for where personal data lives and who can access it, and answering that question costs vastly less when the data sits in one place instead of scattered across ten databases. The price is an occasional extra API call on the product side — far smaller than "every product is a potential breach point."

Member data is like cash: better concentrated in one safe than stuffed a little into every drawer. The more drawers, the less you can explain where the money is.

Decision three: sync via outbox plus webhook — no real-time strong consistency

When data changes in the identity center (a user updates their nickname, say), each product's mirror has to catch up. Our approach is outbox + webhook: on every change, the identity center first writes a "pending event" into its own database within the same transaction (the outbox), then a background process pushes the event to each product via webhook (a system-to-system push notification); the product updates its mirror on receipt. If an event is ever missed, there's a compensating mechanism: "when you use the data and find it stale, pull fresh in real time."

Why not chase real-time strong consistency? Because a nickname arriving a few seconds late at another product is completely imperceptible to the business — but binding multiple systems into one transaction for the sake of "absolutely real-time" means any single product going down can drag login down with it. Not worth it. Figuring out which data can tolerate delay is the cheapest question in distributed architecture. Authentication itself (the tokens issued at login) is real-time; personal-data lookups are real-time; only the display mirror fields go async. Treat the layers differently and the system ends up both stable and cheap.

Account merging: the dirty work you'll face sooner or later

One last reminder about the problem everyone postpones until it can't be postponed: account merging. The moment you offer both email registration and third-party login (Google, Apple, LINE), the same person will end up with two accounts — guaranteed. Merging isn't just combining two member records: orders, points, and history on both products' sides have to move too, and after the move the old identifier still needs a redirect mapping, or every historical link breaks. Our advice: design "merge" as a first-class feature in the identity center's very first version. A crude, manually reviewed version is fine — just don't pretend the problem doesn't exist.

A member center is the kind of infrastructure where nobody praises you for getting it right and you firefight daily for getting it wrong. If you're about to launch a second product, or you're already in pain from multiple membership systems, come talk to us — we can lay out the road we've walked. You can also start with our custom systems and SaaS services to see how we help companies build this kind of shared infrastructure. And if you're also wrestling with app-side architecture, our Capacitor field notes on shipping to both app stores from one codebase is worth a read.