Backend Services
What Is a Backend Service?
A Backend Service is a discrete, deployable unit of software that performs business logic on behalf of consumers — typically other services, APIs, applications, or automated processes. Unlike a front-end application (which users interact with directly), a backend service operates behind the scenes: receiving requests, executing logic, reading from and writing to data stores, and returning results.
Backend services are the workhorses of modern architectures. They encapsulate domain logic, enforce business rules, manage data access, and expose interfaces (APIs, message queues, event streams) through which the rest of the solution interacts with them.
Common examples include:
- Domain services — encapsulate core business logic for a specific domain (e.g. a Pricing Service, an Inventory Service)
- Integration services — orchestrate calls to multiple downstream systems or APIs to fulfil a request
- Data services — provide read/write access to a data store, abstracting away the underlying storage mechanism
- Adapter services — translate between protocols or data formats, often bridging an external system to an internal one
- Worker services — process tasks asynchronously, consuming from a queue or event stream
Why Document Backend Services in an Architecture Repository?
Backend services are the building blocks from which a solution is assembled. Without documenting them, the architecture exists only in people’s heads — and when those people change, so does the institutional knowledge.
Documenting backend services in ArchRepo provides:
- Structural clarity — a clear picture of what services exist, what each one does, and how they relate to one another
- Traceability — link services to the business processes, requirements, and outcomes they support, so delivery can be traced end-to-end
- Dependency visibility — see which services depend on which APIs, data stores, and streams
- Impact analysis — when planning a change to a service or its dependencies, understand what will be affected before making it
- Non-functional coverage — associate availability, performance, security, observability, and other quality mechanisms directly with the service
- Delivery tracking — use status, transition states, estimation, and tasks to track design and implementation progress
Backend Services in ArchRepo
In ArchRepo, backend services are model items identified by an auto-generated reference in the format SVC-1, SVC-2, etc.
Each service can be marked as external — meaning it is operated by a third party and consumed by the solution, rather than being owned and built internally. External services are important to identify because changes to them are outside your control.
Backend services support:
- Status and transition states — track progress from specification through to live and decommissioned
- Categories — group services (e.g. by domain, by team, by layer) and view them in the Services by Category view
- Estimation — record effort estimates for planning and sizing
- Data mapping — trace how data flows into and out of the service across data sets
- Relationships to APIs, data stores, streams, business processes, requirements, NFRs, and architectural quality mechanisms
Relating Services to APIs
A backend service typically has two kinds of API relationship:
- Contains → link to the APIs that this service provides to other consumers. The API is considered part of the service’s public interface.
- Uses → link to the APIs that this service calls — either internal APIs exposed by other services, or external third-party APIs.
Modelling both directions makes it straightforward to answer “what APIs does this service expose?” and “what external APIs does this service depend on?” — essential information for impact analysis and service decomposition.
Relating Services to Data Stores
ArchRepo provides three relationship types for linking a service to a data store, reflecting the level of access the service holds:
- Has Read Access — the service reads from the data store but does not write to it
- Has Write Access — the service writes to (and may read from) the data store
- Has Admin Access — the service has administrative control over the data store (e.g. schema migrations, user management)
Distinguishing access levels is valuable for security reviews, data governance, and understanding the blast radius of a service failure or compromise.
Fields Reference
See Backend Service Fields for a description of each field and guidance on what to record.