Une architecture qui grandit, sans payer pour une échelle que vous n'avez pas
Construit pour la taille d'aujourd'hui avec les bonnes coutures pour demain, et honnête sur ce qui est permanent et ce qui est provisoire.
Évolutif ne veut pas dire construit pour un million d'utilisateurs que vous n'avez pas. Payer cela dès le premier jour, c'est ainsi que meurent les budgets. Cela veut dire construit pour que la croissance change la facture, pas l'architecture : les décisions chères prises avec soin, les décisions réversibles prises vite, et une liste honnête de qui est quoi.
Les décisions réellement permanentes
- Le modèle de données. Tout le reste se remplace ; dix mille enregistrements mal formés vous suivront à travers chaque réécriture. C'est là que nous passons le temps de conception.
- Qui possède quelle donnée. Quand deux systèmes se croient chacun la source de vérité, la croissance transforme le désaccord en corruption.
- Les coutures. L'endroit où une partie du système s'arrête et où l'autre commence décide de ce que vous pourrez remplacer plus tard sans toucher au reste.
- Les identifiants et l'historique. Pouvoir répondre à « à quoi cela ressemblait-il en mars dernier » se décide au départ, en silence.
Comment la croissance arrive vraiment
Pas en courbe régulière. En pic le jour où la presse vous cite, en partenaire qui veut une API au trimestre prochain, en second marché qui double les données. Concevoir pour cela, ce n'est pas ajouter de la capacité, c'est faire en sorte que le pic frappe une partie du système qui grandit en payant plus, pas en reconstruisant. Sans état quand c'est possible, la base gérée, le travail lent mis en file plutôt que bloquant, et du cache là où les lectures écrasent les écritures.
Quand nous conseillons de refondre, et quand non
- Pas quand la facture croît linéairement avec l'usage. C'est le succès, correctement tarifé.
- Pas quand une page est lente. C'est un diagnostic et une correction, une semaine au plus.
- Oui quand la courbe de coût plie du mauvais côté : chaque nouveau client coûte plus cher à servir que le précédent.
- Oui quand une décision permanente de la liste ci-dessus se révèle fausse. C'est exactement la reconstruction qui vaut son prix, et elle est rare quand la liste a été prise au sérieux au départ.
- 10x la charge contre laquelle chaque conception est vérifiée
- 4 décisions traitées comme permanentes, le reste provisoire
- 0 microservice tant que la taille de l'équipe ne le justifie pas
L'architecture, c'est décider quelles erreurs seront bon marché. Le reste est de la capacité, et la capacité n'est que de l'argent.
Questions fréquentes
Est-ce que cela tiendra dix fois le trafic ?
La réponse honnête est un chiffre, pas un oui : chaque conception que nous livrons est vérifiée contre dix fois la charge actuelle, et nous vous disons quel composant atteint son plafond en premier et ce que coûte de le relever. Un système ne passe pas à l'échelle en général, il tient jusqu'à un goulot précis — et savoir lequel est tout le jeu.
Avons-nous besoin de microservices ?
Presque certainement pas encore. Les microservices échangent de la complexité de code contre de la complexité d'exploitation, et l'échange ne paie que lorsque plusieurs équipes se marchent dessus dans une même base. En dessous de cette taille, c'est un système distribué que vous exploitez pour le plaisir d'en exploiter un. Un monolithe bien cousu donne les mêmes options futures sans le coût présent.
Et si nous dépassons ce que vous avez construit ?
Alors il a fait son travail — la version qui convient à votre quarantième salarié ne doit pas être celle qui convenait au quatrième. Parce que les coutures et le modèle de données étaient la partie soignée, dépasser signifie généralement remplacer un composant, pas le système. Et parce que le code et la documentation vous appartiennent, vous pouvez le faire avec nous ou avec n'importe qui.