Introduction: Why This Balance Matters More Than You Think
Backend architecture discussions often collapse into shallow debates about frameworks or cloud providers. That's a mistake. The real long-term cost in backend systems comes from misplaced responsibilities—logic living in APIs that should be in services, cross-cutting concerns leaking into business code, or middleware abused as a dumping ground. Martin Fowler has repeatedly emphasized that architecture is about decisions that are hard to change. How you balance APIs, services, and middleware is one of those decisions, whether you admit it or not.
In theory, everyone agrees on “separation of concerns.” In practice, deadlines, team structure, and legacy constraints push teams into blurry boundaries. APIs start orchestrating workflows. Services start knowing about HTTP. Middleware becomes a grab bag of hacks. This doesn't break systems immediately—it slowly erodes them. Complexity compounds, onboarding slows down, and every change feels riskier than it should. This article is about drawing hard lines, understanding when to bend them, and knowing the consequences when you do.
APIs: The Contract, Not the Brain
An API's primary job is to expose a contract. That's it. Whether it's REST, GraphQL, or gRPC, the API layer should translate external requests into internal calls and translate internal responses back into external representations. Roy Fielding's REST dissertation makes this explicit: the interface is a constraint, not a business engine. When APIs start making business decisions, you've already lost architectural clarity—even if the code still “works.”
A clean API layer focuses on concerns like request validation, authentication delegation, serialization, versioning, and protocol-level errors. It should not contain pricing rules, eligibility logic, or workflow branching. Those belong elsewhere. When APIs grow brains, you create tight coupling to transport details, making reuse and testing harder. This is why experienced teams can swap REST for GraphQL or add async consumers without rewriting core logic—the intelligence lives below the API boundary.
There are edge cases. Backend-for-Frontend (BFF) patterns, popularized by Sam Newman and Netflix, intentionally push orchestration into the API layer. That's fine—but it's a conscious trade-off, not an accident. A BFF is still not where domain rules belong. It coordinates services, shapes responses, and optimizes for a specific client. If you can't clearly explain why logic lives in your API, it probably shouldn't be there.
Services: Where Business Logic Must Live
Services are where your system earns its keep. This is where business rules, domain invariants, and workflows belong. Eric Evans' Domain-Driven Design is blunt about this: if your domain logic is scattered across controllers, middleware, and persistence layers, you don't have a model—you have a mess. Services should be boring in the best possible way: deterministic, testable, and largely unaware of how they're exposed to the outside world.
A well-designed service layer does not care whether it's called via HTTP, a message queue, a cron job, or a test harness. This independence is what allows teams to evolve architectures over time—from monoliths to modular monoliths to microservices—without rewriting the core of the system. Amazon's internal service-oriented architecture famously enforced this separation by mandating that teams expose functionality only through well-defined service interfaces, not shared databases or libraries.
Services should also own transactional boundaries and consistency decisions. Whether you use ACID transactions, sagas, or eventual consistency is a service-level concern, not an API concern. Pushing this logic upward leads to fragile systems that fail in unpredictable ways under load or partial outages.
Middleware: Power Tool, Not a Junk Drawer
Middleware exists to handle cross-cutting concerns—things that apply broadly and uniformly across requests. Logging, metrics, authentication hooks, rate limiting, correlation IDs, and request tracing are classic examples. Frameworks like Express, Fastify, Spring Boot, and ASP.NET Core all formalize middleware or filters for this exact reason. Used correctly, middleware reduces duplication and keeps your core logic clean.
The problem is that middleware is too easy to misuse. Because it sits in the request pipeline, developers are tempted to sneak in business rules, feature flags, or conditional routing. This feels convenient at first, but it creates invisible control flow. Debugging becomes painful because behavior depends on middleware order, configuration, and environment. AWS has repeatedly warned against overloading Lambda middleware with business logic for exactly this reason—it obscures intent and complicates observability.
Here's a good middleware example in JavaScript:
// Request correlation middleware
export function correlationIdMiddleware(req, res, next) {
const correlationId = req.headers['x-correlation-id'] || crypto.randomUUID();
req.correlationId = correlationId;
res.setHeader('x-correlation-id', correlationId);
next();
}
This middleware is stateless, generic, and reusable. It doesn't care about users, orders, or payments. The moment your middleware starts branching on domain concepts, you should stop and rethink your design.
The Real Trade-offs: Performance, Teams, and Cognitive Load
Architectural purity is useless if it ignores reality. Teams split responsibilities differently based on size, skills, and deployment constraints. In small teams, collapsing API and service layers can be pragmatic. In high-throughput systems, avoiding excessive abstraction layers can reduce latency. These trade-offs are real—and pretending otherwise leads to dogma instead of engineering.
However, trade-offs must be explicit. If you blur layers for performance, measure it. If you mix concerns to move faster, document it. This is where Architecture Decision Records (ADRs), advocated by Michael Nygard, pay for themselves. They turn “we did this because it felt right” into “we did this because X, accepted Y risk, and will revisit when Z happens.” That clarity matters more than perfect layering.
Cognitive load is the hidden killer. When developers can't quickly answer “where does this logic live?”, velocity drops. Onboarding takes longer. Bugs hide longer. Balancing APIs, services, and middleware isn't about academic correctness—it's about reducing the mental overhead required to make safe changes. Systems that respect clear boundaries age better. Period.
The 80/20 Rule: The Few Decisions That Matter Most
Roughly 80% of backend pain comes from 20% of architectural mistakes. The biggest one is misplacing business logic. If you fix only that—by keeping APIs thin, services authoritative, and middleware generic—you'll eliminate most long-term friction. This isn't theory; it's a pattern repeated across systems documented by Fowler, Evans, and large-scale cloud providers like AWS and Google.
The second high-impact decision is consistency in enforcement. Having rules is useless if teams violate them casually. Linting, code reviews, and architectural tests (for example, using tools like ArchUnit or dependency rules) help keep boundaries intact. The third is observability placement: middleware for correlation and metrics, services for domain-level signals. Get these right, and your system becomes understandable under pressure, not just on diagrams.
Practical Takeaways: Five Actions You Can Apply This Month
First, audit your API layer. List every piece of logic it contains and ask whether it's protocol-related or business-related. Move the latter down. Second, identify one core service and write tests that call it without HTTP involved. If that's painful, you've coupled layers too tightly.
Third, review your middleware stack and delete anything that knows about domain concepts. Fourth, document at least one architectural trade-off using an ADR—even if it feels obvious. Finally, enforce boundaries socially and technically. Architecture isn't self-maintaining; it reflects what teams tolerate.
Conclusion: Architecture Is a Discipline, Not a Diagram
Balancing APIs, services, and middleware is not about following trends or copying Big Tech diagrams. It's about discipline. Clear boundaries force clarity of thought. They make systems easier to reason about, easier to change, and harder to accidentally break. When those boundaries blur, entropy wins—slowly, then all at once.
If you take only one thing away, let it be this: APIs expose, services decide, middleware supports. Break that rule consciously if you must—but never by accident.