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

// 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 user = await fetch(`${USER_SERVICE}/users/${userId}`);
    return this.processOrder(user, items);
  }
}

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

// 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());
  }
}

// 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)

@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
}
```[^4]

**Microservices**:
```typescript
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!
}

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;
  }
}

// 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);

// 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!

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)

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

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

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

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));
  });
});

// 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);

// Left adjoint: free construction
const decompose = (monolith: Monolith): Microservices => {
  // Canonical decomposition
};

// Right adjoint: forgetful/aggregation
const compose = (microservices: Microservices): Monolith => {
  // Canonical composition
};

// Adjunction means these translations are "optimal"

Lambda Function ≅ ECS Task (single container)

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

Single Table Design ≅ Multi-Table Design

If: Proper GSI design mirrors the joins you need
If: Access patterns are known and stable
```[^12]

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

### SQS + Lambda vs. Kinesis + Lambda

---

## The Equivalence Decision Framework

When choosing between architecturally different options:

### 1. Identify the Categories

What are the objects and morphisms in each approach?

### 2. Check Morphism Correspondence

Does every operation in A have an equivalent in B?

### 3. Verify Composition

Do sequential operations compose the same way?

### 4. Identify Breaks

What properties exist in one but not the other?
- Transactions?
- Latency bounds?
- Consistency guarantees?

### 5. Decide Based on Breaks

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

<InfoBox title="The Key Question" type="note">

"Are these architectures equivalent *for my requirements*?"

Not abstractly equivalent—equivalent for what you actually need.

</InfoBox>

---

## The Takeaway

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.*

---

## Footnotes

[^1]: Richard Hamming (1915-1998) was an American mathematician and computer scientist, known for his work on error-correcting codes (Hamming codes) and information theory. This quote reflects his philosophy that computing should serve as a tool for understanding and insight, not mere calculation—directly relevant to architectural equivalence, where we focus on structural insights rather than implementation details.

[^2]: In category theory notation: $\circ$ represents composition of functors, and $\text{Id}_{\mathcal{C}}$ is the identity functor on category $\mathcal{C}$ (which maps every object to itself and every morphism to itself). The equation states that composing the functors $F$ and $G$ in either order gives exactly the identity functor.

[^3]: The symbol $\cong$ means "is isomorphic to" (structurally the same but not necessarily identical), as opposed to $=$ which means strict equality. This weaker condition makes equivalence more practical than isomorphism for real-world architectures, where exact identity is too strict a requirement.

[^4]: The `@Transactional` annotation works in monoliths because both operations target the same database. ACID (Atomicity, Consistency, Isolation, Durability) guarantees ensure both operations either succeed together or fail together. This property doesn't automatically transfer to distributed systems where data lives in different databases or services.

[^5]: The saga pattern was introduced by Hector Garcia-Molina and Kenneth Salem in their 1987 paper "Sagas" (Princeton University). It provides long-lived transactions through compensating actions. AWS Step Functions implements this pattern natively, allowing you to define compensating workflows for distributed transactions. See: [AWS Step Functions](https://aws.amazon.com/step-functions/).

[^6]: Examples of systems where latency differences are critical: High-Frequency Trading (HFT) systems where microseconds matter, industrial control systems with real-time constraints, gaming servers requiring low latency for player experience, and robotics systems with hard real-time deadlines. In these domains, a 100x latency increase breaks functional equivalence.

[^7]: The skeleton of a category is formally defined in Saunders Mac Lane's "Categories for the Working Mathematician" (1971). It's constructed by choosing one representative from each isomorphism class of objects. This construction is unique up to isomorphism, making it a canonical way to simplify category structure while preserving equivalence.

[^8]: Morita equivalence is named after Japanese mathematician Kiiti Morita, who introduced the concept in ring theory in 1958. Two rings are Morita equivalent if their categories of modules are equivalent. This generalizes naturally to databases: two database schemas are Morita equivalent if their categories of queries/views are equivalent, regardless of internal representation.

[^9]: A natural isomorphism is a collection of isomorphisms that "vary naturally" with the objects—meaning the transformation respects the category structure. This is crucial because it means the equivalence isn't arbitrary but follows from the fundamental structure of the architectures. Natural transformations will be covered in detail in Part 8 of this series.

[^10]: Consumer-driven contracts are a pattern where service consumers define the contracts they expect, rather than providers dictating them. Tools like [Pact](https://pact.io/) enable testing these contracts across different implementations. This is particularly useful for verifying architectural equivalence between systems that must satisfy the same client requirements.

[^11]: Adjunctions are pairs of functors with optimal translation properties—they preserve the most structure possible. When an equivalence is also an adjunction (adjoint equivalence), the round-trip translations are not just isomorphic but universal (no other translation is "better"). We'll explore adjunctions in depth in Part 11: "Adjunctions: The Universal Translation Pattern."

[^12]: Rick Houlihan's talks at AWS re:Invent popularized DynamoDB single-table design patterns. Key resources: [AWS DynamoDB single-table design](https://aws.amazon.com/blogs/compute/creating-a-single-table-design-with-amazon-dynamodb/) and his advanced design pattern talks. Single-table design trades schema flexibility for performance and cost optimization when access patterns are well-understood.