A new endpoint can feel like progress: one more clean boundary, one more service, one more place to put business logic. But every boundary has a cost. It adds code to operate, a network hop to debug, and another contract that can drift.
Sometimes the best architecture is the service you decide not to introduce.
Ask what the boundary buys you
A separate API may be valuable when multiple clients need the same contract, when the work belongs to a separately owned domain, or when an independent security boundary is essential. It can also provide a stable interface while an internal implementation changes.
If one application is the only consumer and the new layer merely forwards every request, it may be ceremony. That does not automatically make the existing application better, but it should make the team ask which responsibility is genuinely being separated.
Don't trade simplicity for loose coupling
Direct database access can reduce hops, but it must not bypass authorization, validation, or important domain rules. Put access behind the existing server boundary, use narrowly scoped queries, and verify that each request is authorized for the correct user and tenant.
Likewise, a single service can become difficult to change if unrelated features share hidden assumptions. Organize modules around clear ownership first. Add a network boundary when independent deployment, scaling, or access control justifies the extra operational surface.
Measure the path users experience
Trace the full request. Count the services involved, round trips, failure points, and time spent waiting. Confirm the design with realistic load and access patterns rather than assuming that another layer is automatically faster or safer.
Architecture is a series of tradeoffs, not a contest to create the most boxes. Build the boundary that protects a real responsibility. Leave out the one that only makes a diagram look cleaner.
