You can deploy a single global FusionAuth instance in one region (e.g., US or Japan) and store email addresses and authentication credentials there, while keeping other personal data (like names) in regional profile services.

In this model:

This approach works well when:

For strict data residency requirements, FusionAuth recommends physical isolation where each region gets its own completely separate FusionAuth instance with its own database and web server. This approach:

Tradeoffs: This is more expensive (servers scale linearly with regions), and cross-region reporting requires network calls. Users would also need separate accounts per region, which may not meet your "single identity" requirement.

To maintain consistent configuration across these separate instances, you can use Terraform to sync application and tenant configurations between deployments while keeping user data isolated.

Another pattern involves using IdP hints to route users to region-specific authentication flows while maintaining a unified user experience. With IdP hints, you can bypass the login page and route users directly to the appropriate identity provider based on attributes like email address or domain. This can help direct users to region-specific instances based on their location or organization.

Before finalizing your architecture, consider:

Data classification: Clearly define which identity data must be region-specific vs. what can be stored globally. Under GDPR, email addresses and authentication credentials are considered personal data.

Token validation: Ensure your regional services can validate JWT tokens efficiently. FusionAuth supports distributed token validation where services in any region can verify tokens locally without calling back to the authentication server. See the guidance on JWT validation in microservices architectures.

Compliance review: Verify your chosen approach meets your specific regulatory requirements (GDPR, etc.). FusionAuth is designed with GDPR compliance in mind and supports features like data export, deletion, and consent management.

Cross-domain SSO: If using separate instances per region, note that FusionAuth supports cross-domain single sign-on through OAuth/OIDC flows, though users would still need to authenticate to each regional instance separately unless you implement additional federation layers.

This is a complex architectural decision that benefits from detailed discussion of your specific requirements.