IV. Backing services

Treat backing services as attached resources

“A backing service is any service the app consumes over the network as part of its normal operation.” – 12factor.net

When to use

When connecting to Databases, Queues, Caches, or External APIs.

Why it matters

Portability: You can swap a local MySQL for an Amazon RDS without changing code (just config).
Resilience: You can attach/detach resources at will.

Signs of Violation

Hard/tight coupling to the local file system for storage (instead of S3).
Assuming the database is “localhost”.

Explanation

Problem

If your app assumes the database is “inside” the same server (tightly coupled), you can’t scale the app horizontally without scaling the database too.

Solution

Treat everything (DB, S3, SMTP) as a URL resource. mysql://user:pass@host/db. It doesn’t matter if it’s local or remote.

Real world analogy

A desk lamp. You can plug it into any outlet (Resource) in the house. It doesn’t care if the power comes from a coal plant or a solar panel; it just needs a socket.

Pros and Cons

Pros	Cons
Loose coupling Scalability	Network latency concerns usually handled by proximity

Comparison

Embedded Services: SQLite is an example of an embedded backing service. It’s fine for dev, but 12-factor prefers separate processes for prod.