Principle #4: Backing Services
Goal: Treat any service your application depends on — like databases, caches, or message queues — as an attached resource that can be swapped or reconfigured without changing your code.
What It Means
Backing services are external systems your app uses to function, such as:
- Databases (PostgreSQL, MySQL)
- Caches (Redis, Memcached)
- Message brokers (RabbitMQ, Kafka)
- File storage (AWS S3, Google Cloud Storage)
Key rules:
- Access via config: Connection details should come from environment variables, not be hardcoded.
- Interchangeable: You should be able to replace one service with another without altering application code.
- Remote or local: It doesn’t matter where the service is — the app should treat it the same way.
Why It Matters
- Flexibility: Switch providers or upgrade infrastructure with minimal disruption.
- Scalability: Easily add or replace services as demand grows.
- Disaster recovery: Swap to a backup service quickly if the primary fails.
- Consistency: Keeps code simple and environment-agnostic.
Example
An image-sharing app stores uploaded files:
- In development, it uses a local storage folder.
- In staging and production, it uses Amazon S3.
- The app gets the storage location from an environment variable, so no code changes are needed to switch.
Best Practices
- Treat all backing services as external resources.
- Use environment variables for all connection details.
- Test your app with different service providers.
- Avoid hardcoding credentials or URLs.
- Document all required services for setup.
Takeaway: Treat databases, caches, and other services as replaceable parts connected through configuration, not hardcoded into your app. This makes scaling, upgrading, and recovery far easier.
Top comments (0)