What is functional federation (splitting one database by function/domain into several standalone databases, e.g. a 'users' database and a separate 'orders' database) as a scaling technique, and what trade-off does it introduce compared to keeping everything in one database?

## What functional federation is **Functional federation** - sometimes called **functional partitioning** or **federation by domain** - is a horizontal scaling technique that splits a single, all-encompassing database into multiple independent databases, each responsible for one functional area of the business: - a 'users' database holding accounts and profiles, - an 'orders' database holding order and line-item data, - a 'billing' database holding invoices and payment records, and so on. ## Federation versus sharding This is distinct from sharding: | Technique | What it splits | The resulting shape | |---|---|---| | **Sharding** | a single logical table (say, one enormous 'orders' table) into many pieces by some partition key (customer ID range, hash of an ID) | any one shard holds a slice of the same kind of data | | **Federation** | instead, by kind of data - by subject/domain | each resulting database is smaller not because it holds fewer rows of the same table, but because it holds fewer tables' worth of responsibility altogether | ## How it emerges, and what it buys Mechanically, federation usually emerges as a database naturally follows a service decomposition: as a system moves toward domain-driven or microservice boundaries, each service or bounded context ends up owning its own datastore, and what was once one shared schema becomes several. Each functional database can then be scaled, tuned, and even chosen independently - the orders database might need heavy write throughput and strong consistency, while a catalog/search database might be read-heavy and better served by a document store or search index entirely. This independence is the main payoff: - you're no longer capacity-planning one monolithic instance for the combined peak load of every feature in the product; - each domain's database only has to handle that domain's traffic, - and a spike in, say, checkout traffic doesn't compete for buffer-pool memory or IOPS with an unrelated reporting query against the catalog. ## What it costs The cost is the loss of what a single relational database gives you for free across tables: cross-table joins in one query, and single-transaction ACID guarantees spanning multiple entities. When users and orders live in the same database, 'get a user's name alongside their last 5 orders' is one SQL join; 'debit a wallet balance and create an order row atomically' is one transaction. Once those two concerns live in separate federated databases, neither is available directly. - **A join becomes an application-level join**: query the orders database for order rows, collect the user IDs, query the users database for those users, and stitch the results together in application code - more network round trips, more latency, and often duplicated logic across every service that needs the same join. - **A cross-domain transaction becomes a distributed-transaction problem**: either accept eventual consistency and coordinate via asynchronous events/sagas (create the order, publish an event, have a separate process debit the wallet and compensate/roll back on failure), or reach for genuinely painful mechanisms like two-phase commit, which most teams avoid because it couples availability across services that were split apart specifically to decouple them. ## Referential integrity is a quiet casualty Referential integrity is another quiet casualty: a foreign key from orders to users can no longer be enforced by the database engine once they're different instances, so 'orphaned' references (an order pointing to a deleted user) become an application-level concern to prevent or tolerate, typically via soft deletes, event-driven cleanup, or accepting the occasional dangling reference as a fact of life. Teams commonly compensate by denormalizing small amounts of frequently needed data across the boundary - storing a copy of the user's display name directly on the order row at creation time, refreshed via an event when the name changes - trading a bit of duplication and eventual staleness for avoiding a cross-database join on the hot read path. ## A concrete shape A concrete real-world shape: a growing e-commerce platform starts with one Postgres database holding users, catalog, orders, and reviews. As traffic grows, the team federates it into four databases aligned to service boundaries - a users service database, a catalog service database (which later migrates to Elasticsearch for search), an orders service database, and a reviews service database - each independently scaled. The order-confirmation page, which used to be one SQL join across users/orders/catalog, becomes an API composition layer in the orders service that calls the users and catalog services (or reads locally cached/denormalized copies of the fields it needs) and assembles the response. The net effect matches the general theme of every technique in this space: functional federation buys independent, roughly linear scaling per domain at the price of trading database-enforced consistency and joins for application-owned consistency and composition - the same currency other partitioning techniques spend, just organized along business capabilities rather than row keys.