Equivalence of Categories: When Different Architectures Are 'The Same'

“The purpose of computing is insight, not numbers.”

— Richard Hamming¹

Two architectures look completely different—one is a monolith, the other is microservices. Yet from the perspective of their clients, they’re indistinguishable. This isn’t a coincidence; it’s categorical equivalence. Understanding equivalence tells you when architectural choices don’t matter and when they absolutely do.

An isomorphism between categories is a pair of functors $F: \mathcal{C} \to \mathcal{D}$ and $G: \mathcal{D} \to \mathcal{C}$ such that:

This is strict equality—round-tripping gives you exactly what you started with.²

An equivalence is weaker but more useful:

Round-tripping gives you something isomorphic to what you started with—not identical, but indistinguishable.³

Two architectures are equivalent if:

1. Every capability in Architecture A has a corresponding capability in Architecture B
2. Every capability in Architecture B has a corresponding capability in Architecture A
3. Composing capabilities works the same way in both

Monolith Category:

• Objects: Modules, classes, functions
• Morphisms: Method calls, function invocations

Microservices Category:

• Objects: Services, APIs, message queues
• Morphisms: HTTP calls, events, gRPC

Can these be equivalent? Yes, if:

// Monolith morphism
class OrderModule {
  constructor(private userModule: UserModule) {}

  createOrder(userId: string, items: Item[]): Order {
    const user = this.userModule.getUser(userId);
    return this.processOrder(user, items);
  }
}

// Microservices equivalent
class OrderService {
  async createOrder(userId: string, items: Item[]): Promise<Order> {
    const res = await fetch(`${USER_SERVICE}/users/${userId}`);
    const user = await res.json();
    return this.processOrder(user, items);
  }
}

From the client’s perspective, both provide:

• createOrder(userId, items) → Order

The internal structure differs, but the external interface is equivalent.

For architectures $A$ and $B$ to be equivalent, you need:

Maps monolith structure to microservices:

// F(UserModule) = UserService
// F(OrderModule) = OrderService
// F(userModule.getUser()) = GET /users/{id}
// F(module.method()) = service.endpoint()

Maps microservices back to monolith-like structure:

// G(UserService) = UserClient wrapper
// G(OrderService) = OrderClient wrapper
// G(HTTP call) = method call on client

class UserClient {
  async getUser(id: string): Promise<User> {
    return fetch(`${USER_SERVICE}/users/${id}`).then(r => r.json());
  }
}

$G \circ F \cong \text{Id}_A$: Decomposing then recomposing gives something isomorphic to the original.⁴

// Original monolith call
const result1 = orderModule.createOrder(userId, items);

// Decomposed to microservices, then wrapped in clients
const result2 = await orderClient.createOrder(userId, items);

// Results are isomorphic (same data, different wrapper)

$F \circ G \cong \text{Id}_B$: Composing then decomposing gives something isomorphic.

Equivalence fails when structural properties don’t transfer:

Monolith⁵:

class CheckoutModule {
  constructor(private orderRepo: OrderRepo, private paymentRepo: PaymentRepo) {}

  @Transactional
  async createOrderWithPayment(userId: string, items: Item[]) {
    const order = await this.orderRepo.create(items);
    const payment = await this.paymentRepo.charge(order.total);
    // Both succeed or both fail
  }
}

Microservices:

class CheckoutService {
  async createOrderWithPayment(userId: string, items: Item[]) {
    const order = await orderService.create(items);
    const payment = await paymentService.charge(order.total);
    // What if payment fails? Order already exists!
  }
}

The morphism “atomic create-and-pay” exists in the monolith category but not in the naive microservices category.

To restore equivalence: Add saga/compensation pattern⁶

class CheckoutService {
  async createOrderWithPayment(userId: string, items: Item[]) {
    const order = await orderService.create(items);
    try {
      const payment = await paymentService.charge(order.total);
    } catch (e) {
      await orderService.cancel(order.id);  // Compensating action
      throw e;
    }
  }
}

Now there’s an equivalent morphism (though implemented differently)—but only in a coarsened observational category. Sagas lack isolation: the transient order is visible before compensation runs, compensation itself can fail, and the failure end-state is a cancelled order, not no order. The equivalence holds only if your requirements ignore intermediate states, concurrency, and compensation failure.

// Monolith: ~1ms
const user = userModule.getUser(id);
const orders = orderModule.getOrdersForUser(user);

// Microservices: ~100ms total
const user = await userService.getUser(id);
const orders = await orderService.getOrdersForUser(user);

If latency matters to correctness (real-time systems, trading), these aren’t equivalent—the microservices version can’t meet the same temporal constraints.⁷

-- Monolith: single database, joins are cheap
SELECT o.*, u.*
FROM orders o
JOIN users u ON o.user_id = u.id
WHERE o.total > 1000;

// Microservices: data is distributed
// This query doesn't have a direct equivalent!

Every category has a skeleton: the smallest equivalent category with no isomorphic objects.⁸

Architecture insight: The skeleton is your “essential” architecture—with all redundancy removed.

Original Architecture:
- UserService-v1, UserService-v2, UserService-v3 (all equivalent)
- OrderService-Primary, OrderService-Replica (equivalent)
- PaymentGateway-Stripe, PaymentGateway-Square (same interface)

Skeleton:
- UserService (one representative)
- OrderService (one representative)
- PaymentGateway (one representative)

The skeleton tells you: “This is what you really have, ignoring deployment details.”

1. Simplifies reasoning: Analyze the skeleton, conclusions apply to full system
2. Identifies redundancy: Multiple isomorphic services are one logical service
3. Clarifies dependencies: See the essential dependency graph

Two databases are Morita equivalent if their categories of “modules” (queries, views) are equivalent.⁹

Relational Schema:

CREATE TABLE users (id INT, name VARCHAR, email VARCHAR);
CREATE TABLE orders (id INT, user_id INT, items JSONB);

Document Schema:

// users collection
{ _id: ObjectId, name: String, email: String }

// orders collection
{ _id: ObjectId, userId: ObjectId, items: [...] }

These are Morita equivalent if:

• Every relational query has a document equivalent
• Every document query has a relational equivalent
• Compositions correspond

They’re NOT equivalent when:

• You need multi-document transactions (relational wins)
• You need deep nested documents (document wins)
• You need arbitrary joins (relational wins)
• You need schema flexibility (document wins)

describe('Architecture Equivalence', () => {
  const monolith = new MonolithOrderSystem();
  const microservices = new MicroservicesOrderSystem();

  test.each(orderScenarios)('scenario %s produces equivalent results',
    async (scenario) => {
      const monolithResult = await monolith.execute(scenario);
      const microservicesResult = await microservices.execute(scenario);

      // Results should be isomorphic
      expect(normalize(monolithResult)).toEqual(normalize(microservicesResult));
    }
  );

  test('composition is preserved', async () => {
    // f then g in monolith
    const m1 = await monolith.f(input);
    const m2 = await monolith.g(m1);

    // f then g in microservices
    const s1 = await microservices.f(input);
    const s2 = await microservices.g(s1);

    expect(normalize(m2)).toEqual(normalize(s2));
  });
});

Using consumer-driven contracts:¹⁰

// Both systems must satisfy the same contracts
const userContract = {
  getUser: {
    input: { id: 'string' },
    output: { id: 'string', name: 'string', email: 'string' }
  }
};

// Test monolith against contract
testContract(monolith.userModule, userContract);

// Test microservices against contract
testContract(microservices.userService, userContract);

An adjoint equivalence is an equivalence where the functors form an adjunction (which we’ll cover in Part 11). It’s not a stronger relationship between the categories—every equivalence can be promoted to an adjoint equivalence using the same two functors—but a convenient normalization of one.¹¹

Architectural meaning: The architectures are no more equivalent; adjointness just tidies the translation data so the round-trip witnesses fit together coherently.

// Quasi-inverse pair—each undoes the other up to isomorphism
declare const decompose: (monolith: Monolith) => Microservices;
declare const compose: (microservices: Microservices) => Monolith;

// In an equivalence, each functor is both left and right adjoint
// to the other—no free ⊣ forgetful asymmetry here

For many workloads, these are equivalent:

Lambda Function ≅ ECS Task (single container)

Morphisms:
- invoke(event) → response
- (internal processing)

Equivalent when: Stateless request/response pattern Not equivalent when: Long-running processes, local state needed

Single Table Design ≅ Multi-Table Design

If: Proper GSI design mirrors the joins you need
If: Access patterns are known and stable

Equivalent for: Known access patterns¹² Not equivalent for: Ad-hoc querying, complex reporting

SQS: Pull-based, message-level processing
Kinesis: Push-based, batch processing

Equivalent when: Order doesn't matter, batch size = 1
Not equivalent when: Ordering matters, need replay

When choosing between architecturally different options:

What are the objects and morphisms in each approach?

Does every operation in A have an equivalent in B?

Do sequential operations compose the same way?

What properties exist in one but not the other?

• Transactions?
• Latency bounds?
• Consistency guarantees?

If the breaks don’t matter for your use case, the architectures are equivalent for you.

Equivalence is about preserving what matters:

1. Different implementations can be equivalent if they support the same operations
2. Equivalence is weaker than isomorphism but more practical
3. Test for equivalence by verifying morphism correspondence and composition
4. Breaks in equivalence identify when architectural choice matters

When someone says “monolith vs. microservices”—ask “equivalent for what operations?”

The answer tells you whether the choice matters.

Next in the series: Products and Coproducts: The Algebra of Service Composition — Where we learn the universal patterns for combining and decomposing services.