Enterprise Architecture

🔍 What Is It?

Enterprise Next.js architecture addresses challenges that small apps never face:

• →Team scale — 50+ engineers, multiple feature teams, shared components
• →Codebase scale — thousands of components, hundreds of routes
• →Deployment scale — multiple environments, blue/green deployments, feature flags
• →Multi-tenancy — serving multiple customers from one codebase
• →Compliance — GDPR, SOC2, HIPAA requirements affecting architecture

Key architectural patterns:

• →Monorepo with Turborepo
• →Backend for Frontend (BFF)
• →Data Access Layer (DAL)
• →Feature flags
• →Multi-tenancy via subdomain routing

🎯 Why Do We Need It?

Without architectural guardrails, large Next.js codebases become:

• →Spaghetti imports — components importing from anywhere, circular dependencies
• →Inconsistent patterns — 10 different ways to fetch data
• →Slow builds — rebuilding everything when one file changes
• →Merge conflicts — multiple teams editing the same files
• →Security gaps — no clear boundary between public and private data

🏗️ What Happens in Real Projects?

Enterprise Next.js monorepo structure:

my-enterprise/
├── apps/
│   ├── web/           # Main Next.js app
│   ├── admin/         # Admin Next.js app
│   └── docs/          # Documentation site
├── packages/
│   ├── ui/            # Shared component library
│   ├── db/            # Prisma schema + client
│   ├── auth/          # Auth utilities
│   ├── config/        # Shared ESLint, TypeScript config
│   └── types/         # Shared TypeScript types
└── turbo.json     # Turborepo pipeline config

⚙️ How It Works

The BFF (Backend for Frontend) pattern:

Instead of calling microservices directly from the frontend, the Next.js app acts as a BFF:

1. Client Component calls a Server Action or Route Handler
2. BFF layer aggregates data from multiple microservices
3. BFF transforms data into the shape the frontend needs
4. BFF handles auth, rate limiting, and error normalisation
5. Frontend receives clean, typed data

This decouples the frontend from backend service details and enables frontend-driven API design.

💻 Example

Enterprise Patterns — Data Access Layer, multi-tenancy, and feature flags.

// lib/dal/products.ts — The only place that touches the products table
import { cache } from 'react';
import { db } from '@/lib/db';
import { requireAuth, requirePermission } from '@/lib/auth';

// All product access goes through this layer
// Benefits: single place for auth checks, caching, and query optimisation

export const getProduct = cache(async (id: string) => {
  // Auth check — always enforced at the DAL level
  const session = await requireAuth();
  await requirePermission(session, 'products:read');

  return db.product.findUnique({
    where: { id },
    select: {
      id: true,
      name: true,
      price: true,
      // Never select: passwordHash, internalNotes, costPrice
    },
  });
});

export const getProductsForUser = cache(async (userId: string) => {
  const session = await requireAuth();
  // Users can only see their own products
  if (session.userId !== userId && session.role !== 'admin') {
    throw new Error('Forbidden');
  }
  return db.product.findMany({ where: { ownerId: userId } });
});

🤔 Common Confusions

🚨 Common Production Issues

✅ Best Practices

🏛️ Architect's Note

💬 Frequently Asked Questions

🎯 Key Takeaways

🔗 Related Topics

🎯 Practice this topic in interviews

↗ Where this topic fits