Jan Mikoláš
Glossary
Backend
The backend protects data and business rules outside the user's browser. It is more than a database or a few API endpoints; it also includes integrations, scheduled jobs and operational traceability.
Short definition
The server-side application layer that determines the outcome of an operation.
The backend accepts a request from a web frontend, mobile application or another service, verifies its context and performs the required application logic. It may create an order, calculate a price, retrieve data, write a change to the database or hand work off to an external integration.
The backend boundary is not defined by a single process or repository. A modular monolith, separate API, import worker and scheduled console command can all be parts of the same backend system. The architecture should fit the scope of the product, not a fashionable label.
On a smaller product, one person can also cover full-stack development. That does not remove the need for deeper specialisation in demanding security, data, or operations work.
The problem it solves
Shared rules and data for multiple clients
The backend is where the same rules are applied to an administration interface, online store, mobile application and integration service.
- processing orders, payments, prices, inventory reservations and customer data
- verifying identity and a specific permission before changing data
- an API for the frontend, mobile application, internal system or partner
- imports, exports, webhooks, retries and communication with external services
- scheduled jobs, message queues, logging, monitoring and file processing
Practical example
Changing an order status is more than clicking in an administration interface
The administration interface sends a request to change an order status. The backend loads the order and verifies the user's identity, their permissions in the organisation and the permitted status transition. It stores the change in a database transaction and prepares a follow-up event for the warehouse or carrier.
The frontend can display suitable controls and a clear error, but must not be the only decision point. A user can modify both the client code and the HTTP request itself, so the server always verifies the price, tenant and permissions from its own trusted data.
How it works
From a request to a secure outcome
The diagram describes a common flow, not necessarily separate servers.
- The client sends a request A browser, mobile application or another service calls a URL or API endpoint.
- Entry boundary A web server or reverse proxy forwards the HTTP request to the application and may handle TLS or technical limits.
- Context verification The backend validates the input, authenticates the caller and authorizes the specific action on the specific resource.
- Application logic Services work with a database, cache or integration and enforce domain rules.
- Response or job The client receives a response; longer-running or resilient processing can continue in a message queue.
Important parts
Rules, data and asynchronous work have different responsibilities.
A well-designed backend does not scatter security and business decisions among the client, database and arbitrary endpoints.
Business logic
Describes which changes are possible: for example, an order cannot be confirmed without valid items and an authorized context.
Data consistency
Transactions and constraints protect local state even during concurrent writes. They cannot undo an email already sent or a request to an external API.
Interfaces and integrations
An API, webhook or queue should have a clear contract, security rules and failure behaviour.
Asynchronous jobs
An import, email or inventory synchronisation need not block the response to the user. These jobs require retries, idempotency and monitoring.
Observability
Logs, metrics and correlation identifiers help trace what happened between a request, the database and a remote service.
Benefits and limitations
More services do not automatically make a better backend.
Benefits
- consistent, server-enforced business rules
- a shared API for multiple kinds of clients
- controlled work with data, integrations and asynchronous jobs
- the ability to audit, monitor and correct behaviour without trusting the client
Common mistakes
- treating a database or API as the entire backend
- trusting a price, tenant or role supplied by the client
- allowing a long external call to block every HTTP request
- splitting a simple system into many services without a clear operational reason
When it makes sense
Every application needs a trusted component, though its scope varies.
Even a simple form needs somewhere to validate and securely store its input. For an online store, internal system or marketplace integration, the backend also coordinates multiple steps, permissions, concurrency and failures of external services.
A straightforward modular monolith may suit a small product. A separate frontend, API gateway, workers and multiple services become valuable only when they address genuine needs of the team, operations or independent development.
What to consider
Using a framework alone does not create trustworthiness.
Security, correctness and operational resilience are properties of the design and ongoing checks.
- validate input, identity and permissions on the server
- keep database transactions short and avoid waiting for remote services inside them
- design idempotency and retries for integration writes
- log errors without leaking sensitive data and measure important flows
- test domain rules, the API contract and concurrency failures
Common questions
What a backend is and is not
Is a backend always a PHP application?
No. Backend is a role; it can run in PHP, Go, Python or another technology, and separate workers can perform part of the work.
Is the database part of the backend?
It is a common backend dependency, but not the same thing. The backend decides when and how data is read or changed.
Can the frontend decide permissions?
It can adapt the interface, but the backend must enforce the decision. Both client code and requests can be modified.
Is an API always the entire backend?
No. An API is an interface. The backend behind it includes rules, data, integrations, asynchronous jobs and operational behaviour.
How I use backends in practice
I design backends around real data and integration flows.
In PHP applications, I build online stores, internal systems, APIs and integrations from validation and databases through retries and traceable failures.