DEV Community: Gregory Kulp

Our BFF Was Working. That Was the Problem.

Gregory Kulp — Mon, 08 Jun 2026 13:39:00 +0000

Backend-for-Frontend (BFF) layers solve a real problem.

As systems grow, frontends often need data from multiple APIs, services, runtimes, and data stores. Without some kind of aggregation layer, the browser ends up coordinating requests, understanding backend topology, and stitching together responses.

That was exactly the problem we were trying to solve, right out the gate.

Our frontend wasn't talking to a single backend application. Different capabilities lived in different domains (We are DDD practitioners). Some experiences were powered by query-oriented read models. Others depended on operational runtimes responsible for workflow execution. Identity, billing, reporting, onboarding, and platform configuration all had their own responsibilities.

The frontend didn't need to understand any of that. So we introduced a Backend-for-Frontend layer. Very simple and straightforward, as it was early.

Initially, it worked exactly as intended.

When Should You Use a BFF?

Before I get into the mistake or turnpoint, it's worth answering:

When should you actually introduce a BFF?

A BFF is useful when the frontend needs a stable, experience-oriented API but the backend is intentionally organized around domain ownership. That was our use case at least.

That usually happens when:

the frontend needs data from multiple backend domains
backend APIs are optimized for domain ownership rather than screen rendering
multiple runtimes or services exist behind the scenes
different clients need different API shapes
authentication, tenancy, or request context must be normalized
the frontend should not understand internal service topology

In those situations, a BFF can be a killer boundary.

But a BFF should not be introduced simply because the frontend needs "somewhere to put logic." We had started to creep into that no-go zone and it was showing.

A useful rule of thumb is:

If the code is adapting data for the frontend, it probably belongs in the BFF.

If the code is deciding what the business means, it probably belongs in a domain.

The BFF Became the Easiest Place to Put Things

Every engineering team eventually discovers a dangerous truth:

The easiest place to put a new rule is often the wrong place. (For me it is WAY too easy to place it exactly where the thought came to mind initially... whoops)

Our BFF already had request context, knew who the user was, knew which account was selected, and already called multiple backend services.

So whenever a new feature needed a decision, the BFF looked like a nice drop zone without much after thought.

Need to determine whether reporting should be visible?
Need to determine whether onboarding is complete?
Need to determine whether billing configuration is ready?
Need to determine whether a capability should be enabled?

Put it in the BFF.

Individually, none of those decisions felt problematic. Collectively, they were turning our BFF slowly into a domain layer itself.

The Warning Sign Wasn't Performance

Most architecture problems announce themselves through performance issues in my experience.

This one didn't.

The warning sign was ownership.

As the application evolved, we found ourselves maintaining logic that combined information from multiple parts of the platform:

const canAccess =
  platformReady &&
  billingReady &&
  userHasAccess;

At first glance, this feels completely reasonable.

The problem is not the conditional itself.

The problem was to answer a question like this, the BFF now needs to understand:

readiness state
billing state
account state
user permissions
capability rules

The BFF isn't simply coordinating requests anymore. It is interpreting business meaning and forming logic.

And once that starts happening, every new feature pushes more domain knowledge into the same layer. As we are DDD practitioners, that literally defeats the purpose of bounded ownership.

Information Architecture Exposed the Problem

Ironically, the frontend helped us discover the issue.

As the application grew, the navigation became more explicit:

Settings
├── Users
├── Organization
├── Billing
├── Reporting
├── Integrations
└── Platform Setup

At first glance, looks like a navigation tree.

Architecturally, though, every section represents a domain boundary here.

Billing is not a reporting concern. Reporting is not an identity concern. Identity is not an integration concern.

The navigation structure was forcing us to answer an important question:

Who owns the rules behind each capability?

The BFF was coordinating concerns that belonged to multiple domains.

Coordination was fine. Ownership was not and a real concern.

Read Models Made the Problem More Tempting

We rely heavily on query-oriented read models.

Read models are fantastic for frontend experiences because they provide optimized views of data without exposing the complexity of operational systems.

The challenge is that they also make it very easy to centralize decision-making.

When a BFF has access to:

query results
account state
identity information
configuration status
billing information

all within a single request, it becomes tempting to derive business meaning right there. Over time, the aggregation layer becomes the place where business decisions are made.

That was never a BFFs job.

The Chokepoint Was Real

A BFF is inherently a chokepoint. Every significant frontend interaction flows through it.

The real question isn't whether the BFF becomes a chokepoint. The question is what kind of chokepoint it becomes.

There's a huge difference between:

a composition chokepoint

and

a policy chokepoint

A composition chokepoint assembles information.

A policy chokepoint owns decisions.

Only one of those scales. What does it start to sound like from this mental model?

The Refactor

The solution was narrowing the BFF responsibilities.

During the refactor, we identified several frontend-facing handlers that had accumulated capability evaluation, readiness determination, and cross-domain orchestration responsibilities. Those responsibilities were progressively moved back into domain-owned services while the BFF retained responsibility for composition and response shaping.

Instead of evaluating business rules directly inside frontend-facing handlers, the BFF began asking domain-owned services for answers.

Before, handlers would gather state from multiple places and infer meaning.

const canAccess =
  platformReady &&
  billingReady &&
  userHasAccess;

After the refactor, the BFF became much less authoritative.

Conceptually, the interaction shifted toward something like:

const accessState = await accessService.getAccessState();

return {
  canAccess: accessState.canAccess,
  reason: accessState.reason
};

The BFF still coordinated the experience. The domains owned the decisions.

That shift reduced duplicated logic, clarified ownership boundaries, and made future changes significantly easier to reason about.

What We Learned

Architectural gravity. Every successful BFF accumulates pressure. It sits in the middle of requests, has access to context, and sees information from multiple domains.

It's easy to put decisions there. Resisting that pressure requires deliberate discipline.

Today, we treat our BFF as an adapter and coordinator.

It can:

aggregate
compose
translate
optimize frontend interactions
hide backend topology

But it should not:

own business policy
define capabilities
determine lifecycle state
duplicate domain logic
become the authoritative source of business rules

Those responsibilities belong to the domains themselves.

Because once a BFF starts owning business decisions, it stops being a frontend adapter.

It becomes a second application.

And that's a much harder problem to unwind later.

Quick Glossary

BFF (Backend-for-Frontend): A backend layer designed specifically to support a frontend experience. It typically aggregates data, shapes responses, and hides backend complexity from the UI.

Domain: A business capability that owns its own rules, data, and decisions.

Read Model: A query-optimized view of data designed for retrieval and reporting rather than transactional updates.

Runtime: A backend service or execution environment responsible for operational behavior.

Composition: Combining information from multiple sources into a frontend-friendly response.

Ownership: Responsibility for making and enforcing business decisions.

Questions for You

Have you seen a BFF start accumulating business rules?

How do you decide whether a piece of logic belongs in a domain service versus a frontend-facing layer?

I'd love to hear where you've drawn that boundary in your own systems.

Designing Machine Identity in a Multi-Tenant Platform Is a Trust Problem

Gregory Kulp — Tue, 02 Jun 2026 14:26:42 +0000

Authentication was a breeze. Ownership and trust were harder and led to domain-driven decisions.

TL;DR

Machine Authentication ≠ Trust.

A machine can authenticate successfully and still be the wrong identity for that context.

The real challenge is detailing ownership, tenant boundaries, lifecycle, and trust in a structured way.

The identity problem changed early

Multi-tenancy was never optional for us.

The platform needed strong tenant isolation, clear ownership boundaries, and security rules that could scale across organizations and workflows.

That requirement shaped identity decisions very early.

In a single-tenant app, authentication and authorization are often enough to get started.

In a multi-tenant platform, every access decision eventually becomes a boundary decision.

You start asking questions like:

Who owns this resource?
Which tenant created this data?
Which tenant is this identity acting inside?
Should this action be allowed across tenant boundaries?

That is where permissions alone stop being enough.

A role tells you what an identity/principal can do.

Tenant context tells you where it can do it. For us tenant was a trust/security boundary out the gate.

Both matter.

Our first model worked for day-to-day users

The first version of the system was centered around people.

Users authenticated. ✅
Claims carried context. ✅
Roles grouped permissions. ✅
Scopes represented allowed actions. ✅
Authorization rules decided whether a request could access a protected resource. ✅

A simplified early claim looked like this on paper:

{
  "sub": "user_123",
  "tenant": "tenant_a",
  "roles": ["analyst"],
  "scopes": ["read.records", "write.records"]
}

That model worked well because ownership was usually obvious.

A principal belongs to a tenant.

A request carries tenant context.

Policies can evaluate permission and boundary together.

For your standard day-to-day users, that assumption held up well enough.

And in hindsight, that phase was useful and beneficial as a base to jump from.

It forced us to think carefully about roles, scopes, claims, and tenant boundaries before machine identities entered the picture.

The moment machine identity stopped fitting

It was immediate (no building tension here). The first machine credential forced us to revisit one of our earliest assumptions:

tenant ownership is obvious.

A machine identity might belong to:

a tenant
the platform itself
a specific runtime
an internal service
an external integration acting on behalf of a tenant service accounts
and now autonomous agents acting with minimal guardrails on behalf of tenants AI

That was the point where the model started to feel incomplete or that the linear pathway was insufficient.

At first, machine identity looked like a simple extension of what we already had.

Scopes still mattered.
Claims still mattered.
Authorization still mattered.
Duh ... in many ways it did.

So it was tempting to treat a machine identity as just another principal entering the same policy engine that was running our authz.

A principal identity is usually tied to a person.

A machine identity is tied to a responsibility and bounded operational context for us AND the tenant using it. That changes the design.

Multi-tenancy made the gap obvious

Once machine credentials became first-class actors in the system, the questions changed into a more governable lens.

We also had to ask:

Who created this credential?
Who owns it?
Which tenant does it belong to?
Can it act across tenant boundaries?
Which runtime is allowed to use it?
How is it rotated?
How is it revoked?
How do we audit it later? ... there were more..

Those aren't just authentication questions.

They are ownership questions, lifecycle questions, and trust questions.

It stopped looking like an auth extension and started looking like a domain model by design.

Authentication and trust are not the same thing

This was probably the clearest takeaway.

At the protocol level, machine-to-machine auth can look straightforward (and is here):

issue a credential
validate it
check claims
evaluate policy

But a valid credential can still be the wrong credential.

A signed token can still represent an identity being used outside its intended boundary. A client can authenticate successfully and still be operating in a context the platform should not trust.

That is why this distinction became important:

Authentication ≠ Trust

Authentication asks:

Can this identity prove something about itself?

Trust asks:

Should this identity be allowed to act here, in this context, under these ownership boundaries?

That second question is bigger. And it gets bigger as machines become more autonomous.

The most important question: who owns this credential?

This ended up being the most useful question in the whole space:

Who owns this credential?

Because once that is clear, a lot of other things become easier to define:

tenant scope
allowed actions
allowed runtimes
lifecycle rules
revocation behavior
audit expectations
trust level

And if that answer is unclear, the model is probably still too loose. It largely drove us deeper into domain-driven architecture designs and subsequent decisions early.

That is why I now think machine identity in a multi-tenant platform is really an ownership problem first.

Trust is the consequence of getting ownership right. Of course, this starts to lean into governance and security frameworks. But my goal here is less about prescribing a framework and more about sharing the mental model that helped me reason about the problem.

What made this exciting was how early this IAM / M2M complexity showed up as a real product requirement. That was new for me in pacing, and it forced more mature identity and access patterns across the runtimes involved (all of them lol).

A simple mental model that helped me

If I had to compress the lesson into one simple framework, it would be this:

Human identity:
principal → tenant → permissions

Machine identity:
responsibility → owner → tenant boundary → trust → permissions

It's simplified, but it captures the shift well enough.

For humans, identity usually begins with the person and their relationship to a tenant.

For machines, identity becomes meaningful through ownership and boundary.

Final thoughts

The real design pressure was deciding what a machine identity actually means inside a multi-tenant platform.

Who owns it?
Which boundary does it belong to?
What is it allowed to represent?
Why should the platform trust it in this context?

In multi-tenant systems, machine identity must be about modeling trust.

Tags: #m2m #security #architecture

Quick glossary

Machine identity

Machine identities are digital entities used to identify, authenticate and authorize machines. What is a Machine Identity

Multi-tenant platform

Also called software multitenancy, a single instance of a software application serves multiple tenants (or user accounts). The identity problem changed early

Tenant

A customer, organization, or isolated account boundary inside a multi-tenant system.

Principal

A single identity recognized by a system, such as a user, service, or machine identity.

Credential

Object, doc, or structured data used to prove identity, such as an API key, token, client credential, or similar authentication secret.

Claims

Pieces of identity-related information carried with authentication data, such as tenant, role, or subject. What are claims?

Scopes

Named permissions that define what an identity is allowed to do. Scopes vs Claims

Runtime

A runtime, in general, executes a piece of software. What is runtime?

Trust boundary

A system boundary where identity, ownership, and context must be evaluated before access should be allowed.