Adjunctions: The Formal Structure of Trade-offs

“An adjunction is a pair of functors that are ‘almost inverses’ of each other, in a precise sense.”

You’ve felt this tension: more flexibility means less governance; more governance means less flexibility. More consistency means less availability. These feel like problems to solve, but they’re not—they’re mathematical dualities. Adjunctions formalize this structure, showing why certain trade-offs are necessary and how to navigate them optimally.

An adjunction between categories $\mathcal{C}$ and $\mathcal{D}$ consists of:¹

• A left adjoint functor $F: \mathcal{C} \to \mathcal{D}$
• A right adjoint functor $G: \mathcal{D} \to \mathcal{C}$
• A natural bijection:

We write $F \dashv G$ (“F is left adjoint to G”).

• $F$ is “free”—it constructs with minimal constraints
• $G$ is “forgetful”—it observes while losing structure
• The bijection says: ways to use F’s output = ways to map into G’s output

Sets  ⟵(U)---(F)⟶  Monoids
         G          F

• $F$: Free monoid (generates strings from a set)
• $G$: Forgetful functor (just sees the underlying set)

The adjunction says:

In words: Giving a monoid homomorphism from the free monoid is the same as choosing where generators go.²

// The set: a type
type Generators = 'a' | 'b' | 'c';

// Free monoid: words over an arbitrary set S
type FreeMonoid<S> = S[];

// A target monoid
interface Monoid<M> {
  empty: M;
  combine: (a: M, b: M) => M;
}

// Right adjoint: forgetful, just sees the carrier
type Forget<M> = M;

// The adjunction: homomorphisms from Free ≅ functions to carrier
const adjunction = <M>(
  monoid: Monoid<M>,
  assignment: (g: Generators) => M  // Function S → U(M)
): ((free: FreeMonoid<Generators>) => M) => {   // Homomorphism F(S) → M
  return (free: FreeMonoid<Generators>) =>
    free.reduce((acc, g) => monoid.combine(acc, assignment(g)), monoid.empty);
};

Many architectural patterns have adjoint structure:³

Flexible System  ⟵(Make Flexible)---(Observe)⟶  Constrained System

One warning before the table, because it’s easy to get wrong: the systems below are not adjoints. Functors are adjoints; systems are just objects. Read the columns as the two sides of the correspondence—shorthand for where each functor lands. And watch which side is which: in Sets ↔ Monoids, the free functor lands on the more-structured side (monoids), while the forgetful functor lands on the less-structured side (sets). Architectural “flexibility” usually names the less-structured side—the forgetful functor’s home turf, not the free functor’s.

Read the central formula again, carefully, because it’s easy to get backwards:

This is a statement of equivalence, not scarcity. The bijection says the two descriptions are interchangeable: every way of using the free construction corresponds to exactly one way of mapping into the forgetful view, and the correspondence is natural—you can translate back and forth for free, as often as you like.

So where does the trade-off live? In the unit and counit, which are not invertible. Going from $C$ into $G(F(C))$, the free construction adds structure you never specified. Going from $F(G(D))$ back to $D$, the forgetful view has already discarded structure you had. The adjunction organizes free translation between two perspectives; what each direction must add or forget is where the cost lives.

It’s tempting to say the CAP theorem is an adjunction in disguise. Resist the temptation—it isn’t one, and seeing why sharpens both ideas.

CAP is an impossibility theorem: under a network partition, no system can offer both strong consistency and full availability.⁴ An adjunction is the opposite kind of statement—a correspondence. If a hom-set bijection related consistent-side specifications to available-side specifications, it would say the two specs carry equivalent information. That’s the opposite of impossibility. CAP itself is not the bijection, and no amount of squinting makes it one.

What can be adjunction-flavored is the pair of translations between the two worlds. Take categories of systems annotated with their consistency guarantees, and a pair of functors between them:

Available Systems  ⟵(Weaken)---(Strengthen)⟶  Consistent Systems
                       G               F

• $F$: Strengthen—add the coordination required to meet a consistency contract
• $G$: Weaken—forget guarantees, keep the behavior

If these form an adjunction, the correspondence reads:

That’s a claim about translating specifications—not a way around CAP. The trade-off lives where it always does: strengthening adds coordination (and its latency) you never asked for; weakening discards guarantees you were relying on. And CAP remains standing outside the whole construction, as the hard limit on what any strengthening can deliver during a partition.

// Consistent system
interface ConsistentDB<T> {
  read(): Promise<{ value: T; version: number }>;
  write(value: T, expectedVersion: number): Promise<boolean>;  // CAS
}

// Available system (weakened view)
interface AvailableDB<T> {
  read(): Promise<T>;  // May be stale
  write(value: T): Promise<void>;  // Always succeeds locally
}

// The adjunction-flavored claim: programming against ConsistentDB<T>
// corresponds to programming against AvailableDB<T> plus explicit
// conflict resolution—the part that Strengthen has to add

Another fundamental adjunction:

High Performance  ⟵(Scale Up)---(Reduce)⟶  Low Cost
                       F             G

The correspondence:

Same shape as before: this is translation, not scarcity. A design phrased against the scaled-up system can be re-read, exactly, as a design phrased against its reduced view. The trade-off sits in the unit and counit—scaling up provisions capacity you didn’t specify; reducing forgets headroom you had.

// High performance (provisioned)
const provisionedDynamoDB = {
  readCapacityUnits: 10000,
  writeCapacityUnits: 5000,
  // Predictable latency, higher cost
};

// Low cost (on-demand)
const onDemandDynamoDB = {
  billingMode: 'PAY_PER_REQUEST',
  // Variable latency, pay per use
};

// Adjunction: provisioned capacity guarantees are equivalent to
// on-demand costs under specific load patterns

Every adjunction has two special natural transformations:

“Embedding into the free construction”

// Unit: embed a set into its free monoid
const unit = <S>(s: S): FreeMonoid<S> => [s];

// Architecturally: embed simple request into flexible system
const embedRequest = (simpleReq: SimpleRequest): FlexibleRequest => ({
  ...simpleReq,
  metadata: {},
  options: defaults,
});

“Evaluating the free construction”

// Counit: evaluate free monoid in target monoid
const counit = <M>(
  monoid: Monoid<M>,
  free: FreeMonoid<M>
): M =>
  free.reduce((acc, m) => monoid.combine(acc, m), monoid.empty);

// Architecturally: evaluate flexible request in constrained system
const evaluateInConstrained = (
  system: ConstrainedSystem,
  flexReq: FlexibleRequest
): ConstrainedResponse =>
  system.handle(restrictToSchema(flexReq));

The unit and counit satisfy:

Meaning: Not that round-tripping through both functors gets you back where you started—it doesn’t. The free monoid on $U(M)$ is nothing like $M$; if the round trips were identities, we’d have an equivalence of categories, not an adjunction. The triangle identities say something narrower: inserting the unit–counit zig-zag on the image of $F$ or $G$ is a no-op. $F \Rightarrow FGF \Rightarrow F$ is the identity, and so is $G \Rightarrow GFG \Rightarrow G$.

Every adjunction $F \dashv G$ generates a monad $T = G \circ F$ on $\mathcal{C}$.⁵

// The monad from Free ⊣ Forgetful
type FreeMonad<S> = FreeMonoid<S>;  // G(F(S))

// unit: S → G(F(S))
const pure = <S>(s: S): FreeMonad<S> => [s];

// join: G(F(G(F(S)))) → G(F(S))
const flatten = <S>(nested: FreeMonad<FreeMonad<S>>): FreeMonad<S> =>
  nested.flat();

This is why monads appear everywhere in programming—they arise from adjunctions, and adjunctions model trade-offs.

Pick left or right and commit:

// Commit to the flexible side
const flexibleChoice = 'microservices';
// Accept: more operational complexity, coordination costs

// Commit to the constrained side
const constrainedChoice = 'monolith';
// Accept: less flexibility, tighter coupling

Work on the easier side, transport results:⁶

// Problem: design complex consistent transactions
// Easier: design available operations + conflict resolution

// Work in available space
const operations = designAvailableOps();

// Transport to consistent space via adjunction
const transactions = composeWithConflictResolution(operations);

Use unit/counit to transition:

// Start in simple category
const simpleDesign: SimpleSystem = { /* ... */ };

// Apply unit: embed into flexible
const flexibleDesign = unit(simpleDesign);

// Modify in flexible space
const modified = enhance(flexibleDesign);

// Apply counit: evaluate back in constrained
const constrainedResult = counit(targetSystem, modified);

Lambda (Flexible)  ⟵(Extract)---(Containerize)⟶  ECS (Controlled)

• Left: Lambda—flexible scaling, pay-per-invocation
• Right: ECS—controlled resources, predictable behavior

The correspondence, honestly stated: if Containerize ⊣ Extract holds, ways of using a containerized workload correspond to ways of mapping into its extracted, Lambda-shaped view—a bijection of hom-sets, natural in both arguments. It is not an object-level bijection between Lambda configurations and ECS task definitions; that would be an equivalence, and none exists (an ECS task exceeding Lambda’s limits has no Lambda counterpart).

DynamoDB (Flexible Schema)  ⟵(Relax)---(Normalize)⟶  RDS (Rigid Schema)

• Left: DynamoDB—schema flexibility, denormalized
• Right: RDS—schema enforcement, normalized

The correspondence, honestly stated: if Normalize ⊣ Relax holds, ways of using the normalized schema correspond to ways of mapping access patterns into its relaxed view—hom-sets again, not a one-to-one pairing of schemas or queries.

SNS (Pub/Sub)  ⟵(Broadcast)---(Buffer)⟶  SQS (Queue)

• Left: SNS—immediate fanout, fire-and-forget
• Right: SQS—buffered, guaranteed delivery

The correspondence, honestly stated: if Buffer ⊣ Broadcast holds, ways of consuming the buffered topic correspond to ways of mapping into the broadcast view of the queue—a hom-set correspondence, not a claim that every consumer setup has a subscription twin.

Signs you have an adjunction:

“Every way of using one construction matches a way of mapping into the other”—a correspondence of hom-sets, not a one-to-one pairing of the systems themselves

GraphQL queries ↔ REST endpoint compositions
Event handlers ↔ Request handlers
Declarative configs ↔ Imperative scripts

“We can’t have both fully”

Flexibility ↔ Governance
Performance ↔ Cost
Simplicity ↔ Power
Latency ↔ Throughput

“There’s a natural way to go from A to B”—but be precise about what those translations are. A REST-to-GraphQL translation is the action of the functor $F$ itself, carrying objects across categories. It is not the unit: $\eta$ lives entirely inside $\mathcal{C}$, comparing each object with its round-trip image $G(F(C))$, and $\epsilon$ lives entirely inside $\mathcal{D}$.

// The action of F: translate across categories
declare const restToGraphQL: (endpoint: RestEndpoint) => GraphQLResolver;

// The action of G: translate back
declare const graphqlToRest: (resolver: GraphQLResolver) => RestEndpoint;

// The unit stays INSIDE the REST category:
// η: endpoint → graphqlToRest(restToGraphQL(endpoint))

Adjunctions organize architectural trade-offs:

1. Left adjoint (free): constructive—lands on the more-structured side, adding structure you didn’t specify
2. Right adjoint (forgetful): observational—lands on the less-structured side, discarding structure you had
3. Hom-set correspondence: maps out of the free construction match maps into the forgetful view—two interchangeable descriptions of the same information
4. Unit/Counit: the non-invertible round trips—where the actual trade-off lives

When you feel tension between flexibility and constraint:

• Ask whether a pair of translations gives it adjoint structure
• Use the correspondence to work on the easier side
• Remember the cost sits in the unit and counit, not in the bijection

Trade-offs aren’t problems—they’re structure. Navigate them, don’t fight them.

Next in the series: Monads: Cross-Cutting Concerns That Actually Compose — Where we learn how error handling, logging, and effects can be structured categorically.