Design a Multi-Domain Graph Architecture and Decide Which Relationships Belong Local vs Federated

The AtlasMart architecture board must choose between one connected graph, multiple domain databases, separate instances, and an optional Enterprise composite. The decision cannot be “microservices are modern” or “graphs should connect everything.” It must preserve the invariants and traversals that deliver business value while making ownership, security, capacity, failure and recovery tractable. This final lab produces that decision record.

Learning outcomes

Reproducible Chapter 19 lab baseline

1. Relationship placement matrix

2. Reject a split when it breaks the dominant graph workload

3. Final free architecture

from neo4j import GraphDatabase
from time import perf_counter

AUTH = ("neo4j", "atlasmart-course-2026")
drivers = {
    "orders": GraphDatabase.driver("bolt://127.0.0.1:7768", auth=AUTH),
    "customers": GraphDatabase.driver("bolt://127.0.0.1:7769", auth=AUTH),
    "catalog": GraphDatabase.driver("bolt://127.0.0.1:7767", auth=AUTH),
}

def run(domain, query, **params):
    t0 = perf_counter()
    with drivers[domain].session(database="neo4j") as s:
        rows = [r.data() for r in s.run(query, **params)]
    return rows, perf_counter() - t0

order_rows, t_orders = run("orders", """
MATCH (o:Order {orderId:$orderId})-[:PLACED_BY]->(cr:CustomerRef)
MATCH (o)-[li:CONTAINS]->(pr:ProductRef)
RETURN o.orderId AS orderId, o.status AS status,
       cr.customerId AS customerId, pr.productId AS productId,
       li.quantity AS quantity, li.unitPrice AS unitPrice
ORDER BY productId
""", orderId="O-1901")

customer_id = order_rows[0]["customerId"]
product_ids = [r["productId"] for r in order_rows]
customer_rows, t_customers = run("customers", """
MATCH (c:Customer {customerId:$id})
RETURN c.customerId AS customerId, c.name AS customerName, c.tier AS tier
""", id=customer_id)
product_rows, t_catalog = run("catalog", """
MATCH (p:Product) WHERE p.productId IN $ids
RETURN p.productId AS productId, p.name AS productName, p.price AS currentPrice
""", ids=product_ids)

products = {p["productId"]: p for p in product_rows}
result = {
    "orderId": order_rows[0]["orderId"],
    "status": order_rows[0]["status"],
    "customer": customer_rows[0],
    "lines": [{**r, **products[r["productId"]]} for r in order_rows],
}
print(result)
print({"orders_s": t_orders, "customers_s": t_customers, "catalog_s": t_catalog})
for d in drivers.values(): d.close()

4. Optional Enterprise architecture

If self-managed Enterprise is justified, the same domain stores can be standard databases and exposed through a composite namespace. Keep the architecture diagram honest: the composite is a query/federation layer. Draw Catalog/Orders/Customers as the data-bearing recovery/security units underneath it.

// OPTIONAL: self-managed Neo4j Enterprise 2026.07.1; run administration against system.
CYPHER 25
CREATE DATABASE `atlasmart-catalog` IF NOT EXISTS;
CREATE DATABASE `atlasmart-orders` IF NOT EXISTS;
CREATE DATABASE `atlasmart-customers` IF NOT EXISTS;
CREATE COMPOSITE DATABASE atlasmart IF NOT EXISTS DEFAULT LANGUAGE CYPHER 25;
CREATE ALIAS atlasmart.catalog IF NOT EXISTS FOR DATABASE `atlasmart-catalog`;
CREATE ALIAS atlasmart.orders IF NOT EXISTS FOR DATABASE `atlasmart-orders`;
CREATE ALIAS atlasmart.customers IF NOT EXISTS FOR DATABASE `atlasmart-customers`;

SHOW DATABASE atlasmart YIELD name, type, currentStatus, constituents, defaultLanguage;
SHOW ALIASES FOR DATABASE
YIELD name, composite, database, location, url, credentials, user
WHERE composite = 'atlasmart'
RETURN * ORDER BY name;

CYPHER 25
CALL {
  USE atlasmart.orders
  MATCH (o:Order {orderId:$orderId})-[:PLACED_BY]->(cr:CustomerRef)
  MATCH (o)-[li:CONTAINS]->(pr:ProductRef)
  RETURN o.orderId AS orderId, o.status AS status,
         cr.customerId AS customerId, pr.productId AS productId,
         li.quantity AS quantity, li.unitPrice AS unitPrice
}
CALL {
  USE atlasmart.customers
  WITH customerId
  MATCH (c:Customer {customerId:customerId})
  RETURN c.name AS customerName, c.tier AS tier
}
CALL {
  USE atlasmart.catalog
  WITH productId
  MATCH (p:Product {productId:productId})
  RETURN p.name AS productName, p.price AS currentPrice
}
RETURN orderId, status, customerId, customerName, tier,
       productId, productName, quantity, unitPrice, currentPrice
ORDER BY productId;

5. Failure-domain acceptance test

6. Migration and rollback plan

7. Cost model

8. Final verification and cleanup

Before cleanup, rerun the fixture verification and O-1901 federation probe. Preserve only the architecture decision record and measured evidence—not the synthetic password or disposable stores.

CYPHER 25
// Run on catalog
MATCH (p:Product {labTag:'ch19'}) RETURN count(p) AS products;
// Expected: 3

// Run on customers
MATCH (c:Customer {labTag:'ch19'}) RETURN count(c) AS customers;
// Expected: 3

// Run on orders
MATCH (o:Order {labTag:'ch19'}) RETURN count(o) AS orders;
MATCH (:Order {labTag:'ch19'})-[r:CONTAINS]->(:ProductRef) RETURN count(r) AS lines;
// Expected: orders=3, lines=4

# Remove disposable Chapter 19 Community instances and their data volumes.
docker rm -f atlasmart-ch19-catalog atlasmart-ch19-orders atlasmart-ch19-customers
docker volume rm atlasmart-ch19-catalog-data atlasmart-ch19-orders-data atlasmart-ch19-customers-data
docker network rm atlasmart-ch19-net

Production judgment

Chapter 19 completion checklist

Summary and next step

Chapter 19 turns multi-database federation into a domain architecture discipline: data stays in owned constituent stores, identities cross boundaries as explicit values, federation is measured, and security/recovery/versioning remain per-domain responsibilities. Chapter 20 can now build change-data-capture and event integration on top of these ownership boundaries without confusing CDC with cross-database atomicity.

Authoritative references

• Current Neo4j versions — Current self-managed release 2026.07.1 and 5.26.30 LTS snapshot.
• Database administration — Current database/transaction-domain model and the one-standard-database Community versus multi-database Enterprise boundary.
• Create standard databases — Enterprise-only self-managed CREATE DATABASE semantics and system-database administration.
• Show databases — SHOW DATABASES fields including type, role, writer, status, aliases and constituents.
• Composite database concepts — Enterprise-only, unavailable-on-Aura composite semantics, local/remote constituents, compatibility, transactions and proxy-node federation.
• Create composite databases — CREATE COMPOSITE DATABASE and current default Cypher language behavior.
• Query composite databases — USE/CALL graph selection, graph functions, update restrictions, root-scope limits and runtime behavior.
• Composite aliases — Local and remote constituent aliases, SHOW ALIASES evidence, namespace rules and alias limitations.
• Standard aliases — Local/remote alias behavior, credentials, access visibility and current OIDC-forwarding option for remote aliases.
• Composite RBAC — Access must be granted to the composite and constituents; remote constituents enforce remote-user RBAC.
• Composite tutorial — Official federation/sharding example and proxy-node model.
• Database alias command syntax — Current SHOW/CREATE/ALTER alias command forms.
• Cypher USE clause — Current graph-selection clause semantics for composite/federated queries.
• Python driver manual — Official driver lifecycle, sessions, parameters, database selection and application-side orchestration.
• Backup and restore — Operational reminder that constituent data stores—not a composite alias layer—are the recovery units.