A mobile application can have a perfect UI and still feel unreliable because the backend allows impossible states.
The most important backend skills are not framework-specific.
They are understanding what can go wrong when multiple requests happen at the same time, networks fail halfway through an operation, clients retry, and one business action touches several database records.
Transactions protect business invariants
Imagine an order confirmation that must:
- Create the order.
- Reserve stock.
- Create payment records.
- Update the customer balance.
If step 3 fails after steps 1 and 2 succeed, the database can enter a state the business never intended.
A transaction lets those changes succeed or fail as one unit.
The important question is not “Should I use a transaction?”
It is “Which business invariant must remain true if any line of this operation fails?”
That is a much better way to design transaction boundaries.
Idempotency makes retries safe
Mobile networks fail in ugly ways.
Sometimes the server completes the operation but the client never receives the response.
The user taps again.
The app retries.
Without idempotency, “retry” can become “duplicate charge,” “duplicate invoice,” or “duplicate transfer.”
A good pattern is to attach an idempotency key or stable operation ID to important commands.
The backend stores the result for that operation identity and returns the same logical result if the request is repeated.
Retries become safe instead of dangerous.
Concurrency is not a queue in your controller
Two users can update the same inventory row at nearly the same time.
Reading quantity = 1, then subtracting 1 in two separate requests can produce overselling if both requests read before either writes.
The solution might involve:
- Atomic SQL updates.
- Row-level locks.
- Optimistic version columns.
- Serializable transactions.
- Unique constraints.
- Domain-specific reservation models.
The correct choice depends on contention and business rules.
The important part is to solve concurrency in the database and domain model, not by hoping requests arrive one at a time.
Constraints are part of the application
I like databases that reject invalid states even if application code has a bug.
Useful tools include:
- NOT NULL constraints.
- Unique constraints.
- Foreign keys.
- CHECK constraints.
- Proper numeric types.
- Transaction boundaries.
Validation in the API is good for user feedback.
Constraints in the database are good for correctness.
You often want both.
Retries need classification
Not every failure should be retried.
A timeout may be retryable.
A 429 may be retryable after a delay.
A 500 may be retryable depending on the operation.
A validation error is usually not.
An authentication error may require token refresh before retry.
A conflict may require the user or domain logic to make a decision.
Blind retry loops create load and hide real problems.
Design the failure path first
For important commands, I like to ask:
- What if the request runs twice?
- What if the DB fails after the first write?
- What if the user closes the app?
- What if two users modify the same record?
- What if the response is lost?
- What if a background worker retries later?
Those questions produce better APIs than starting with the happy-path controller.
Backend engineering is largely about making sure the system remains correct when the happy path stops being happy.