MFA (Multi-Factor Authentication): After password, the user proves identity with a second factor (SMS, app, hardware key). Implement via an auth provider (Clerk, Auth0, Firebase Auth) or standards (TOTP, WebAuthn). The backend validates the second factor before issuing a session or token.

SSO (Single Sign-On): Users log in once (e.g. corporate IdP); they get a token or session that your app trusts. Implement with SAML or OAuth 2.0 / OIDC. Your app redirects to the IdP; after login, the IdP redirects back with a token. The backend validates the token and maps it to a user. Full stack impact: frontend handles redirects and token storage; backend validates tokens and enforces permissions.

Blue/green: Two identical environments (blue, green); you deploy to the idle one, test, then switch traffic (e.g. load balancer) to the new one. Instant rollback by switching back. Canary: Send a small % of traffic to the new version; if metrics are good, increase; if not, roll back. Rolling: Replace instances one by one with the new version. All require health checks and a way to route traffic; often used with containers or serverless.

For full stack: frontend (static) is often deployed by replacing assets (cache invalidation). Backend and DB migrations need care—backward-compatible APIs and migrations that can run while the old version is still live.

When you deploy a new backend that expects a new schema, run migrations in a way that does not break the old version still receiving traffic. Prefer additive changes first (add column nullable, add table); then deploy code that can read old and new; then backfill or migrate data; then deploy code that requires the new shape; finally remove the old column/table in a later release. Backward compatibility: Do not remove or rename API fields in one release; deprecate first and remove later so clients have time to migrate.