05. IV. Backing services

Trata los backing services como recursos conectables.

¿Qué es un backing service?

Un backing service es cualquier recurso que la aplicación consume por red como parte de su funcionamiento normal:

• Bases de datos: MySQL, PostgreSQL, CouchDB.
• Sistemas de mensajería/colas: RabbitMQ, Beanstalkd.
• Cachés: Memcached, Redis/Valkey.
• Servicios de correo: Postfix, Postmark.
• APIs de terceros: Amazon S3, Twitter, Google Maps, Stripe.

Local o de terceros: no hay diferencia

El principio central del factor IV: el código de la aplicación no distingue entre un servicio local y uno de terceros. Ambos son recursos que se acceden por URL/credenciales declaradas en configuración (Factor III), y ambos deben poder intercambiarse sin tocar código.

flowchart LR
    App["Aplicación"] -->|DATABASE_URL| DB[("PostgreSQL local<br/>o Amazon RDS")]
    App -->|SMTP_URL| Mail["Postfix local<br/>o Postmark"]
    App -->|REDIS_URL| Cache[("Redis local<br/>o servicio gestionado")]

Ejemplo práctico de intercambiabilidad

Si tu app usa DATABASE_URL para conectarse a PostgreSQL, deberías poder pasar de una instancia local a Amazon RDS cambiando sólo el valor de esa variable de entorno — cero cambios de código. Lo mismo aplica si necesitás reemplazar un servidor SMTP propio por Postmark, o un caché en memoria por un Redis gestionado.

Esta propiedad es la que permite operaciones como:

• Restaurar la base de datos desde un backup en un servidor nuevo sin redeploy de la app.
• Migrar de un proveedor cloud a otro cambiando endpoints, no lógica.
• Probar en desarrollo contra un servicio distinto al de producción del mismo tipo (ver también Factor X, donde se recomienda que sea del mismo tipo y versión).

Checklist del factor IV

• Todo recurso externo (DB, cola, caché, API) se accede vía una URL/credencial en configuración, nunca hardcodeado.
• El código no tiene ramas if es_produccion para decidir cómo hablarle a un backing service local vs. uno de terceros.
• Reemplazar un backing service por otro del mismo tipo es, en la práctica, sólo un cambio de variable de entorno.

Con el código, las dependencias, la configuración y los recursos externos resueltos, el siguiente factor define cómo ese código se convierte en un proceso corriendo: build, release, run.