Inbox pattern на собеседовании системного аналитика

Зачем inbox

Symmetric к outbox. Inbox — на receiving side.

Problem. At-least-once delivery → duplicates. Receiver обрабатывает event дважды.

Solution. Save event в inbox table. Process once. Subsequent deliveries — ignored.

Implementation

CREATE TABLE inbox (
  event_id TEXT PRIMARY KEY,
  payload JSON,
  received_at TIMESTAMP DEFAULT NOW(),
  processed BOOLEAN DEFAULT FALSE,
  processed_at TIMESTAMP
);

-- on receive
INSERT INTO inbox (event_id, payload) VALUES (...) ON CONFLICT DO NOTHING;
COMMIT;

-- worker processes
SELECT * FROM inbox WHERE NOT processed FOR UPDATE SKIP LOCKED LIMIT 100;
-- process
UPDATE inbox SET processed = TRUE, processed_at = NOW() WHERE event_id = ...;

Idempotency

ON CONFLICT DO NOTHING — duplicate insert ignored. Event_id PK gives this.

Processing — happens только once (worker locks row).

Result published / saved — atomic с processed=true.

Ordering

Если order matters — process events in order.

Per-aggregate ordering. Events для same Order processed sequentially. Different Orders — parallel.

SELECT * FROM inbox WHERE NOT processed AND aggregate_id = $X
ORDER BY received_at LIMIT 1;

Per-aggregate worker / queue.

В Kafka — same partition guarantees order. Inbox preserves через aggregate_id grouping.

Vs outbox

Both часто used together — outbox publishes, inbox consumes. End-to-end atomic.

Связанные темы

• Outbox pattern для SA
• Idempotency key для SA
• Event-driven архитектура для SA
• Domain events для SA
• Подготовка к собесу системного аналитика

FAQ

Это официальная информация?

Нет. Статья основана на работах Chris Richardson (microservices.io).

Тренируйте системный анализ — откройте тренажёр с 1500+ вопросами для собесов.