Ошибка	Последствие
Считать событийно-ориентированную систему сильно согласованной	Ложные ожидания — по природе она лишь итогово согласована
Думать, что события — это просто логирование	Упустить, что событие и есть реальный канал общения компонентов
Направлять зависимости наружу — домен импортирует драйвер БД	Бизнес-правила привязаны к хранилищу, край не заменить
Путать слои с отдельно развёртываемыми сервисами	Неверная модель — слои живут внутри одного процесса
Переиспользовать одну `struct` как DTO и доменную сущность	JSON-теги и форма API текут в бизнес-логику
Считать, что relay из outbox публикует внутри той же транзакции	Неверная модель — relay работает отдельно, после коммита
Верить, что outbox требует распределённый 2PC	Упустить главное — его смысл обойтись одной локальной транзакцией
Менять местами at-least-once и at-most-once	at-least-once задваивает, at-most-once теряет — не наоборот
Считать, что брокер даёт сквозной exactly-once бесплатно	Дубликаты дойдут до потребителя без его дедупликации
Слать `ACK` до обработки сообщения	Падение посреди обработчика теряет сообщение — брокер не повторит
Считать, что одна ACID-транзакция охватит две базы данных	Изоляция кончается на границе БД — нужна saga или 2PC

advanced

System Design in Go — Asynchrony Is Never Free

Event-driven and layered architecture, the adapter pattern, DTO versus domain entity, the outbox pattern, and message delivery guarantees.

go-system-design

Practice: 18 questions →

Sections

Contents

Detailed explanation

System Design in Go — Asynchrony Is Never Free

While your service calls functions inside a single process, everything is simple — a call either returns a result or fails, and the compiler watches the types. System design begins where that simplicity is gone: components talk through a broker, data lives in different databases, and a process crash can land between the DB write and the event publish. Here the interviewer checks not knowledge of a buzzword, but the ability to reason about consistency under asynchrony.

The central trap of this topic is carrying synchronous-call intuition into a distributed system. In a monolith a write and an event publish are atomic because they are one call. Split them across two systems and atomicity is gone: you get a dual-write, you get partial failure, you get only eventual consistency. The second trap is belief in "free" guarantees: that the broker provides exactly-once on its own, that a single ACID transaction spans two databases, that a redelivery can simply be ignored. This topic breaks system design into layers — from how components communicate down to how exactly a message arrives effectively once.

Topic Map

Event-driven architecture — components communicate through a broker with events instead of direct calls; what it buys and what it costs.
Layered architecture — splitting into transport, domain, and storage, and the rule that dependencies point inward.
The adapter pattern — a stable internal interface hiding a volatile external API or format.
DTO versus domain entity — a transport-shaped data carrier versus a holder of business state, invariants, and behaviour.
The outbox pattern — how one local transaction solves the dual-write problem, and why a saga is needed when there are several databases.
Message delivery guarantees — at-most-once, at-least-once, and effectively-once, and why idempotency is mandatory under retries.

Common Mistakes and Traps

Mistake	Consequence
Treating an event-driven system as strongly consistent	False expectations — it is only eventually consistent by nature
Thinking events are just logging	Missing that the event itself is the real communication channel
Pointing dependencies outward — the domain imports the DB driver	Business rules are coupled to storage, no edge can be swapped
Confusing layers with separately deployed services	Wrong model — layers live inside one process
Reusing one `struct` as DTO and domain entity	JSON tags and the API shape leak into business logic
Thinking the outbox relay publishes inside the same transaction	Wrong model — the relay runs separately, after commit
Believing the outbox needs a distributed 2PC	Missing the point — its goal is to avoid one with a local transaction
Swapping at-least-once and at-most-once	at-least-once duplicates, at-most-once loses — not the reverse
Believing the broker gives end-to-end exactly-once for free	Duplicates reach the consumer without its own deduplication
Sending `ACK` before processing the message	A crash mid-handler loses the message — the broker won't redeliver
Thinking one ACID transaction can span two databases	Isolation stops at the DB boundary — a saga or 2PC is needed

Interview Relevance

System design is a mandatory topic at the senior level of a Go interview, and the question is not a whiteboard diagram but an understanding of consistency. The interviewer checks whether you blindly carry monolith intuition into a distributed system.

What interviewers usually check:

What event-driven architecture pays for loose coupling — asynchrony, harder debugging, only eventual consistency.
The rule of layered architecture — dependencies point inward, the domain imports neither transport nor DB.
Why an adapter is needed — to absorb a change in an external API in one place behind a stable interface.
Why a DTO and a domain entity are separate types, and what leaks if you merge them.
What the dual-write problem is and how the outbox pattern solves it with one local transaction.
How at-least-once differs from at-most-once and why at-least-once is safe only with an idempotent handler.
How to keep two services with separate databases consistent — a saga with compensating transactions, not a single ACID transaction.

A typical wrong answer: "the broker guarantees exactly-once itself, the consumer has nothing to do." This triggers a discussion that end-to-end exactly-once in a distributed system is practically unreachable and is approximated as effectively-once — at-least-once plus deduplication by an idempotency key on the consumer side.

Why it matters

System design separates a developer who writes one service from one who assembles a system out of many. Start exchanging events through a broker, split data across several databases, or trust "message delivery" — and naive assumptions about consistency turn into lost payments, duplicated orders, and bugs you cannot reproduce in a debugger.

Ошибка	Последствие
Считать событийно-ориентированную систему сильно согласованной	Ложные ожидания — по природе она лишь итогово согласована
Думать, что события — это просто логирование	Упустить, что событие и есть реальный канал общения компонентов
Направлять зависимости наружу — домен импортирует драйвер БД	Бизнес-правила привязаны к хранилищу, край не заменить
Путать слои с отдельно развёртываемыми сервисами	Неверная модель — слои живут внутри одного процесса
Переиспользовать одну `struct` как DTO и доменную сущность	JSON-теги и форма API текут в бизнес-логику
Считать, что relay из outbox публикует внутри той же транзакции	Неверная модель — relay работает отдельно, после коммита
Верить, что outbox требует распределённый 2PC	Упустить главное — его смысл обойтись одной локальной транзакцией
Менять местами at-least-once и at-most-once	at-least-once задваивает, at-most-once теряет — не наоборот
Считать, что брокер даёт сквозной exactly-once бесплатно	Дубликаты дойдут до потребителя без его дедупликации
Слать `ACK` до обработки сообщения	Падение посреди обработчика теряет сообщение — брокер не повторит
Считать, что одна ACID-транзакция охватит две базы данных	Изоляция кончается на границе БД — нужна saga или 2PC

advanced

System Design in Go — Asynchrony Is Never Free

Event-driven and layered architecture, the adapter pattern, DTO versus domain entity, the outbox pattern, and message delivery guarantees.

go-system-design

Practice: 18 questions →

Sections

Contents

Detailed explanation

System Design in Go — Asynchrony Is Never Free

Topic Map

Event-driven architecture — components communicate through a broker with events instead of direct calls; what it buys and what it costs.
Layered architecture — splitting into transport, domain, and storage, and the rule that dependencies point inward.
The adapter pattern — a stable internal interface hiding a volatile external API or format.
DTO versus domain entity — a transport-shaped data carrier versus a holder of business state, invariants, and behaviour.
The outbox pattern — how one local transaction solves the dual-write problem, and why a saga is needed when there are several databases.
Message delivery guarantees — at-most-once, at-least-once, and effectively-once, and why idempotency is mandatory under retries.

Common Mistakes and Traps

Mistake	Consequence
Treating an event-driven system as strongly consistent	False expectations — it is only eventually consistent by nature
Thinking events are just logging	Missing that the event itself is the real communication channel
Pointing dependencies outward — the domain imports the DB driver	Business rules are coupled to storage, no edge can be swapped
Confusing layers with separately deployed services	Wrong model — layers live inside one process
Reusing one `struct` as DTO and domain entity	JSON tags and the API shape leak into business logic
Thinking the outbox relay publishes inside the same transaction	Wrong model — the relay runs separately, after commit
Believing the outbox needs a distributed 2PC	Missing the point — its goal is to avoid one with a local transaction
Swapping at-least-once and at-most-once	at-least-once duplicates, at-most-once loses — not the reverse
Believing the broker gives end-to-end exactly-once for free	Duplicates reach the consumer without its own deduplication
Sending `ACK` before processing the message	A crash mid-handler loses the message — the broker won't redeliver
Thinking one ACID transaction can span two databases	Isolation stops at the DB boundary — a saga or 2PC is needed

Interview Relevance

What interviewers usually check:

What event-driven architecture pays for loose coupling — asynchrony, harder debugging, only eventual consistency.
The rule of layered architecture — dependencies point inward, the domain imports neither transport nor DB.
Why an adapter is needed — to absorb a change in an external API in one place behind a stable interface.
Why a DTO and a domain entity are separate types, and what leaks if you merge them.
What the dual-write problem is and how the outbox pattern solves it with one local transaction.
How at-least-once differs from at-most-once and why at-least-once is safe only with an idempotent handler.
How to keep two services with separate databases consistent — a saga with compensating transactions, not a single ACID transaction.

Why it matters

Системный дизайн в Go — асинхронность не бывает бесплатной

Системный дизайн в Go — асинхронность не бывает бесплатной

Карта темы

Частые ошибки и ловушки

Значение для собеседований

System Design in Go — Asynchrony Is Never Free

System Design in Go — Asynchrony Is Never Free

Topic Map

Common Mistakes and Traps

Interview Relevance

Системный дизайн в Go — асинхронность не бывает бесплатной

Системный дизайн в Go — асинхронность не бывает бесплатной

Карта темы

Частые ошибки и ловушки

Значение для собеседований

System Design in Go — Asynchrony Is Never Free

System Design in Go — Asynchrony Is Never Free

Topic Map

Common Mistakes and Traps

Interview Relevance