Какие таблицы и сущности нужны в базе данных, чтобы система обработки событий была поддерживаемой и расследуемой?

Основные сущности для системы обработки событий

Чтобы система обработки событий была поддерживаемой и расследуемой, необходимо проектировать базу данных с учетом хранения не только текущего состояния, но и всей истории изменений. Ключевые таблицы включают:

• events — основная таблица для хранения всех событий. Каждая запись содержит уникальный идентификатор события, тип, источник, время создания и полезную нагрузку (payload) в формате JSON или XML.
• event_processing — таблица для отслеживания статуса обработки каждого события. Здесь хранятся статус (новое, в обработке, обработано, ошибка), количество попыток, время последней попытки и идентификатор обработчика.
• event_errors — таблица для логирования ошибок, возникших при обработке. Содержит код ошибки, сообщение, стек вызовов и ссылку на событие.
• event_metadata — таблица для хранения дополнительных метаданных, таких как версия схемы события, идентификатор пользователя или системы-источника, что упрощает фильтрацию и анализ.

Практический пример схемы

CREATE TABLE events (
  id BIGSERIAL PRIMARY KEY,
  event_type VARCHAR(100) NOT NULL,
  source VARCHAR(255) NOT NULL,
  created_at TIMESTAMP WITH TIME ZONE DEFAULT NOW(),
  payload JSONB NOT NULL
);

CREATE TABLE event_processing (
  event_id BIGINT PRIMARY KEY REFERENCES events(id),
  status VARCHAR(20) NOT NULL DEFAULT 'pending',
  attempts INT DEFAULT 0,
  last_attempt_at TIMESTAMP WITH TIME ZONE,
  handler_id VARCHAR(255)
);

CREATE TABLE event_errors (
  id BIGSERIAL PRIMARY KEY,
  event_id BIGINT REFERENCES events(id),
  error_code VARCHAR(100),
  error_message TEXT,
  stack_trace TEXT,
  occurred_at TIMESTAMP WITH TIME ZONE DEFAULT NOW()
);

Почему это важно

Такая структура позволяет легко воспроизводить события, анализировать ошибки и обеспечивать идемпотентность обработки. Например, если обработчик упал, можно посмотреть в event_errors, исправить баг и перезапустить обработку, не теряя данные. Также это помогает в аудите: всегда видно, кто и когда создал событие, и как оно было обработано.

Вывод

Используйте подобную схему, когда требуется надежная и прозрачная обработка событий, особенно в микросервисной архитектуре или системах с высокими требованиями к отказоустойчивости и расследованию инцидентов.