Ce que ce choix change
Le choix modifie la contention, les limites réseau et les frontières de défaillance. La séparation n'est utile que lorsque le bénéfice opérationnel justifie un autre hôte, un chemin d'authentification supplémentaire et une procédure de reprise supplémentaire.
Comparez les facteurs de décision
| Facteur | API et base de données sur un seul VPS | VPS d'application et de base de données séparés |
|---|---|---|
| Chemin de requête | La connexion locale évite un saut réseau entre hôtes. | Chaque requête dépend de la route réseau et de son authentification. |
| Contention des ressources | L'API, les workers et la base de données partagent le CPU, la RAM et l'activité disque. | Chaque hôte dispose d'un budget de ressources séparé. |
| Frontière de défaillance | Un événement sur un hôte peut affecter l'application et la base de données simultanément. | Une défaillance de l'hôte d'application n'arrête pas nécessairement la base de données, mais le service a toujours besoin des deux. |
| Portée d'accès | Une frontière d'administration unique peut atteindre les deux composants. | L'administration de la base de données peut utiliser une frontière d'hôte et de réseau plus étroite. |
| Planification des connexions | Les pools locaux ont toujours besoin de limites entre l'API et les workers. | Les pools ont besoin de limites ainsi que de décisions sur les délais d'attente réseau et les tentatives. |
| Reprise | Une reconstruction unique doit reconstruire les deux rôles et leurs versions compatibles. | Chaque restauration et la connexion application-base de données doivent être testées ensemble. |
Quand chaque option mérite sa place
Gardez une petite stack combinée tant que le chevauchement mesuré tient avec de la réserve et qu'une frontière de maintenance unique est acceptable. Séparez la base de données lorsque ses exigences de ressources, d'accès ou de reprise sont devenues indépendamment importantes.