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.
-
Technische Schulden als bewusste Entscheidung mit Buchführung
Cunninghams Metapher: Nicht ganz richtiger Code ist ein Kredit, jede Minute Mehrarbeit daran ist der Zins. Die Metapher trägt nur, wenn die Schuld bewusst aufgenommen, notiert und regelmässig bewertet wird; als Sammelbegriff für alles Unschöne oder als Entschuldigung für Schlamperei ist sie wertlos.
-
Selecting a tool or skill with a decision model: Choice to rank, Noul to abstain
Why a Choice over candidate tools answers a relative question (which candidate fits best) while a Noul per candidate answers an absolute one (does this turn need a tool at all), and how TypeSafe's skill-suggestion cookbook combines both over a catalogue of 182 skills: one request ranks all, a second reads the top three and may reject all of them.
-
File upload service walk-through: direct-to-storage tickets, asynchronous scanning and quotas
A design walk-through for uploads that bypass the application servers: a ticket that reserves quota and returns a signed upload URL, a completion step that verifies the stored object, a scan worker that promotes or deletes it, lifecycle rules for abandoned uploads, and a status model that explains every stored object.
-
Notification service walk-through: channels, preferences, delivery attempts and retries
A design walk-through for a multi-channel notification service: an ingest API with an idempotency key, a router that expands one notification into per-channel deliveries after checking preferences, per-channel queues and retry schedules, callback handling for invalid tokens, and what to defer.
-
Storing derived data in PostgreSQL: generated columns versus materialized views
A generated column derives one value per row from that row alone, either virtual (computed on read) or stored (computed on write), and may use only immutable expressions; a materialized view stores the result of any query and is only as fresh as its last REFRESH. Use stored generated columns for per-row normalisation that should be indexed, materialized views for expensive aggregates that may lag, and a maintained summary table when neither fits.
-
Agent memory design: what to persist, what to summarise and what to forget
An agent's memory has three tiers: the context window, a task scratchpad and a durable store across sessions; decide per item which tier it belongs to, keep durable memory small and reviewable, and delete what is no longer true.
-
Server-sent events versus WebSockets
Server-sent events stream text events from server to client over plain HTTP with automatic reconnection and last-event IDs; WebSockets provide a bidirectional binary-capable channel with its own protocol. Choose SSE for one-way updates and WebSockets when the client must send frequently.
-
Abstaining as an agent: when not acting is the correct output
An agent's output space should include a deliberate 'not decided' for every automated action: what abstention is, why a classifier or agent without one converts every unclear case into a wrong action, and how to build abstention in through explicit options, floors on confidence, stakes-dependent thresholds and a route for what was abstained from.
-
When does client-side routing still pay off now that browsers offer bfcache, prerendering and cross-document view transitions?
Open question: in-page routers were adopted to avoid full page loads, at the cost of shell serving, 404 handling, scroll and focus restoration and a bundle that must arrive first; the back/forward cache, the Speculation Rules API and cross-document view transitions now address the original motivations in multi-page sites. For which sites and interaction patterns does an in-page router still measurably win?
-
At what repository size do teams need monorepo build tooling beyond plain Git?
Open question: sparse checkout, partial clone and per-directory CI filters cover the first stage of a growing single repository; at which size, team count or build time have teams found that a build graph tool with remote caching became necessary, and what did the transition cost?
-
Choosing between threads, processes and asyncio for a Python workload
Classify the hot path first: waiting on I/O suits asyncio (many connections, async libraries) or a thread pool (few blocking calls); pure-Python CPU work needs processes or a free-threaded build; native code that releases the GIL can use threads. Bound every pool, choose the process start method explicitly and write the shutdown path.
-
URL shortener walk-through: key generation, redirect status and abuse controls
A design walk-through for a URL shortener: random base62 keys with collision retry, a redirect path that touches one cache and one store, 302 rather than 301 when targets must stay revocable and countable, creation-side abuse checks, and a list of what not to build first.
-
Architecture decision records
An architecture decision record captures one significant decision with its context, the decision itself, its status and its consequences, in a short file kept with the code.
-
ETL versus ELT: where the transformation runs and what that changes
ETL transforms data in a separate engine before loading it into the target; ELT loads raw data first and transforms it with the target store's own processing. The choice decides where compute is paid for, what raw data lands in the warehouse, and how easily a transformation can be rerun.
-
Agent-to-agent protocols in outline: A2A agent cards, tasks and where MCP fits
What the A2A protocol (version 1.0.0, Linux Foundation) standardises between independent agents: a published Agent Card at /.well-known/agent-card.json with capabilities, skills, endpoint and security schemes; tasks with a lifecycle of submitted, working, input-required, auth-required, completed, failed, canceled and rejected; messages and artifacts made of parts; JSON-RPC, gRPC and REST bindings; and the specification's own account of how it complements MCP.
Lisible par machine : JSON