Тема: architecture
-
Конвейер, fan-out, оркестратор и коллегия критиков: какой паттерн мультиагентной системы подходит для какой задачи
Конвейер подходит для задач с фиксированной последовательностью преобразований; параллельный fan-out — для независимых подвопросов или для нескольких попыток, по которым потом проводится голосование; оркестратор с воркерами — для задач, чья декомпозиция становится известна только во время выполнения; коллегия критиков — для результатов, которые нужно проверить по нескольким критериям; каждый из этих паттернов увеличивает расход токенов и добавляет уровень координации, который может дать сбой сам по себе.
-
DACI и RACI для технических решений: один утверждающий, поимённые участники
DACI называет драйвера, который ведёт процесс принятия решения, единственного утверждающего (approver), который его принимает, участников (contributors), у которых есть голос, но нет права вето, и информируемых (informed), которые узнают об итоге. RACI распределяет по задачам роли ответственного за исполнение (responsible), подотчётного (accountable), консультируемого (consulted) и информируемого (informed). Обе модели работают для технических решений, если роли зафиксированы письменно до начала обсуждения.
-
Соглашения внедрения зависимостей в .NET: время жизни, области видимости и ловушка captive dependency
Microsoft.Extensions.DependencyInjection регистрирует сервисы в IServiceCollection со временем жизни transient, scoped или singleton и внедряет их через публичные конструкторы; задокументированные правила гласят: никогда не внедрять scoped-сервис в singleton, позволять контейнеру самому освобождать то, что он создал, избегать вызовов в стиле service locator и включать валидацию областей видимости, чтобы captive dependency обнаруживалась ошибкой при старте, а не утечкой состояния между запросами.
-
Event sourcing and CQRS: what they buy and what they cost
Event sourcing stores every state change as an immutable event and derives current state by replay; CQRS separates the write model from read models. Both add auditability and flexibility at the price of complexity and eventual consistency.
-
Choosing Go or Rust for a new service: a decision procedure without benchmarks
Decide between Go and Rust for a service from documented language properties and team constraints rather than from benchmark folklore: memory management model, error and concurrency style, the shape of the workload, the libraries the service must talk to, and who will maintain it in two years.
-
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.
Машиночитаемо: JSON