Sujet : architecture
-
Pipeline, répartition parallèle, orchestrateur et comité de relecture : quel patron multi-agent pour quelle tâche
Un pipeline convient aux tâches formées d'une séquence fixe de transformations ; la répartition parallèle (fan-out), aux sous-questions indépendantes ou aux tentatives répétées dont les résultats sont soumis au vote ; un orchestrateur avec des agents exécutants, aux tâches dont la décomposition n'est connue qu'à l'exécution ; un comité de relecture, aux résultats à évaluer selon plusieurs critères. Chaque patron multiplie le coût en tokens et ajoute une couche de coordination susceptible de connaître ses propres défaillances.
-
DACI et RACI pour les décisions techniques : un seul approbateur, des contributeurs nommés
DACI désigne un pilote qui mène le processus de décision, un unique approbateur qui prend la décision, des contributeurs qui ont voix au chapitre mais pas de droit de vote, et des personnes informées du résultat ; RACI attribue aux tâches des rôles de responsable de l'exécution, de responsable devant rendre des comptes, de consulté et d'informé. Les deux conviennent aux décisions techniques lorsque les rôles sont consignés avant le début de la discussion.
-
Conventions d'injection de dépendances en .NET : durées de vie, portées et piège de la dépendance captive
Microsoft.Extensions.DependencyInjection enregistre les services dans un IServiceCollection avec une durée de vie transient, scoped ou singleton et les injecte via des constructeurs publics ; les règles documentées sont de ne jamais injecter un service scoped dans un singleton, de laisser le conteneur libérer ce qu'il a créé, d'éviter les appels de type localisateur de services et de valider les portées pour que les dépendances captives provoquent un échec au démarrage plutôt qu'un partage d'état indu entre requêtes.
-
Event sourcing et CQRS : leurs avantages et leurs coûts
L’event sourcing enregistre chaque changement d’état sous forme d’événement immuable et reconstitue l’état courant par rejeu ; CQRS sépare le modèle d’écriture des modèles de lecture. Tous deux apportent de l’auditabilité et de la souplesse au prix d’une complexité accrue et d’une cohérence à terme.
-
Choisir Go ou Rust pour un nouveau service : une procédure de décision sans benchmarks
Choisir entre Go et Rust pour un service à partir des propriétés documentées des langages et des contraintes de l’équipe plutôt que d’idées reçues sur les benchmarks : gestion de la mémoire, traitement des erreurs et concurrence, profil de la charge, bibliothèques nécessaires et personnes qui assureront la maintenance dans deux ans.
-
La dette technique comme décision consciente et comptabilisée
La métaphore de Cunningham : du code pas tout à fait juste est un crédit, et chaque minute de travail supplémentaire qu'il entraîne en est l'intérêt. La métaphore ne tient que si la dette est contractée consciemment, notée et évaluée régulièrement ; comme terme fourre-tout pour tout ce qui est disgracieux, ou comme excuse à la négligence, elle ne vaut rien.
-
Choisir un outil ou une compétence avec un modèle de décision : Choice pour classer, Noul pour s'abstenir
Pourquoi un Choice portant sur des outils candidats répond à une question relative (quel candidat convient le mieux) alors qu'un Noul par candidat répond à une question absolue (ce tour a-t-il seulement besoin d'un outil), et comment le cookbook de suggestion de compétences de TypeSafe combine les deux sur un catalogue de 182 compétences : une première requête classe tous les candidats, une seconde lit les trois premiers et peut tous les rejeter.
-
Étude de cas d'un service de téléversement de fichiers : tickets directs vers le stockage, analyse asynchrone et quotas
Une étude de conception pour des téléversements qui contournent les serveurs d'application : un ticket qui réserve un quota et renvoie une URL de téléversement signée, une étape de finalisation qui vérifie l'objet stocké, un worker d'analyse qui le promeut ou le supprime, des règles de cycle de vie pour les téléversements abandonnés, et un modèle de statut qui explique chaque objet stocké.
-
Étude de cas d'un service de notification : canaux, préférences, tentatives de livraison et nouvelles tentatives
Une étude de conception pour un service de notification multicanal : une API d'ingestion avec une clé d'idempotence, un routeur qui déploie une notification en livraisons par canal après vérification des préférences, des files d'attente et des calendriers de nouvelles tentatives par canal, la gestion des callbacks pour les jetons invalides, et ce qu'il faut différer.
-
Stocker des données dérivées dans PostgreSQL : colonnes générées contre vues matérialisées
Une colonne générée dérive une valeur par ligne à partir de cette seule ligne, soit virtuelle (calculée à la lecture), soit stockée (calculée à l'écriture), et ne peut utiliser que des expressions immuables ; une vue matérialisée stocke le résultat d'une requête quelconque et n'est fraîche qu'à hauteur de son dernier REFRESH. Utiliser des colonnes générées stockées pour la normalisation par ligne qui doit être indexée, des vues matérialisées pour les agrégats coûteux qui peuvent accuser un retard, et une table de synthèse maintenue lorsque ni l'une ni l'autre ne convient.
-
Conception de la mémoire d'un agent : ce qu'il faut conserver, résumer et oublier
La mémoire d'un agent comporte trois niveaux : la fenêtre de contexte, un bloc-notes de tâche et un stockage durable entre sessions ; décider pour chaque élément à quel niveau il appartient, garder la mémoire durable petite et révisable, et supprimer ce qui n'est plus vrai.
-
Server-sent events contre WebSockets
Les server-sent events diffusent des événements textuels du serveur vers le client sur du HTTP simple, avec reconnexion automatique et identifiants de dernier événement ; les WebSockets offrent un canal bidirectionnel capable de transporter du binaire avec son propre protocole. Choisir SSE pour des mises à jour à sens unique et les WebSockets quand le client doit envoyer fréquemment.
-
S'abstenir en tant qu'agent : quand ne pas agir est le résultat correct
L'espace de sortie d'un agent devrait comporter un « non décidé » délibéré pour chaque action automatisée : ce qu'est l'abstention, pourquoi un classificateur ou un agent qui en est dépourvu convertit chaque cas ambigu en action erronée, et comment intégrer l'abstention par des options explicites, des planchers de confiance, des seuils dépendant des enjeux et un acheminement pour ce dont on s'est abstenu.
-
Quand le routage côté client reste-t-il rentable maintenant que les navigateurs offrent bfcache, le prérendu et les transitions de vue entre documents ?
Question ouverte : les routeurs internes à la page ont été adoptés pour éviter les rechargements complets de page, au prix de la desserte d'une coquille (shell), de la gestion des 404, de la restauration du défilement et du focus, et d'un paquet (bundle) qui doit arriver en premier ; le cache avant/arrière (back/forward cache), la Speculation Rules API et les transitions de vue entre documents répondent désormais aux motivations d'origine dans les sites multipages. Pour quels sites et quels schémas d'interaction un routeur interne à la page l'emporte-t-il encore de façon mesurable ?
-
À partir de quelle taille de dépôt une équipe a-t-elle besoin d'outillage de build monorepo au-delà de Git seul ?
Question ouverte : le sparse checkout, le clone partiel et les filtres CI par répertoire couvrent la première étape de la croissance d'un dépôt unique ; à quelle taille, à quel effectif d'équipe ou à quel temps de build les équipes ont-elles constaté qu'un outil de graphe de build avec cache distant devenait nécessaire, et combien cette transition a-t-elle coûté ?
-
Choisir entre threads, processus et asyncio pour une charge de travail Python
Classer d'abord le chemin critique : l'attente d'E/S convient à asyncio (nombreuses connexions, bibliothèques asynchrones) ou à un pool de threads (peu d'appels bloquants) ; le calcul Python pur nécessite des processus ou une build sans GIL (free-threaded). Le code natif qui libère le GIL peut utiliser des threads. Borner chaque pool, choisir explicitement la méthode de démarrage des processus et écrire le chemin d'arrêt.
-
Parcours de conception d'un raccourcisseur d'URL : génération de clés, statut de redirection et contrôles d'abus
Un parcours de conception pour un raccourcisseur d'URL : des clés base62 aléatoires avec nouvelle tentative en cas de collision, un chemin de redirection touchant un seul cache et un seul stockage, 302 plutôt que 301 lorsque les cibles doivent rester révocables et comptables, des contrôles d'abus côté création, et une liste de ce qu'il ne faut pas construire en premier.
-
Fiches de décision d'architecture
Une fiche de décision d'architecture capture une décision significative avec son contexte, la décision elle-même, son statut et ses conséquences, dans un fichier court conservé avec le code.
-
La mise en cache dans les applications : délais d'expiration, invalidation et protection contre la ruée
Un cache applicatif conserve des données dérivées et peut être perdu à tout moment ; il ne reste correct que grâce à une invalidation délibérée : un délai d'expiration par catégorie de données, une suppression plutôt qu'un écrasement à l'écriture, un identifiant de version dans la clé et un verrou contre le rechargement simultané des clés très sollicitées.
-
ETL contre ELT : où s'exécute la transformation et ce que cela change
ETL transforme les données dans un moteur séparé avant de les charger dans la cible ; ELT charge d'abord les données brutes et les transforme avec le traitement propre du magasin cible. Le choix décide où le calcul est payé, quelles données brutes atterrissent dans l'entrepôt, et avec quelle facilité une transformation peut être réexécutée.
Lisible par machine : JSON