Тема «серверные и клиентские события» поддерживает конкретное продуктовое решение. Единица «источник события» — надёжный факт операции и наблюдение пользовательского взаимодействия. Вопрос «источник события»: как разделить ответственность между клиентом и сервером с учётом полноты, задержки и доверия к источнику. Методика «источник события» согласует определения, данные и действия. Владелец «источник события» отвечает за итоговую формулу.
Контекст и цель
Контур «источник события» начинается с будущего решения. Для «источник события» назовите субъект и период. Реакция на изменение «источник события» задаётся заранее. Единица «надёжный факт операции и наблюдение пользовательского взаимодействия» отделяет результат от активности команды. Такой порядок защищает «источник события» от декоративной отчётности.
Основание «источник события»: Google Analytics помогает провести клиентский и серверный сбор. основание
Основание «источник события»: Snowplow поддерживает события с контекстными сущностями. основание
Основание «источник события»: OpenTelemetry определяет событие как именованное происшествие. основание
Основание «источник события»: DebugView показывает поступающие события в — в разборе «Серверные и клиентские события: границы ответственности» — реальном времени. основание
Источники поддерживают принципы «источник события». Локальные фильтры выбирает команда «источник события». Полнота событий проверяется для «источник события» отдельно. Стоимость ошибки также входит в решение «источник события».
Рабочая модель
Формула «источник события»: клиент фиксирует взаимодействие и контекст интерфейса; сервер подтверждает доменный результат и состояние транзакции. Модель «источник события» содержит шесть самостоятельных частей. Каждая часть «источник события» имеет владельца и пример.
-
Пользовательское взаимодействие. В «источник события» элемент «пользовательское взаимодействие» задаёт границу. Пара «пользовательское взаимодействие — доменная операция» проверяется на эпизоде. Исключения «источник события» записываются до расчёта.
-
Доменная операция. В «источник события» элемент «доменная операция» задаёт границу. Пара «доменная операция — источник истины» проверяется на эпизоде. Исключения «источник события» записываются до расчёта.
-
Источник истины. В «источник события» элемент «источник истины» задаёт границу. Пара «источник истины — идемпотентный ключ» проверяется на эпизоде. Исключения «источник события» записываются до расчёта.
-
Идемпотентный ключ. В «источник события» элемент «идемпотентный ключ» задаёт границу. Пара «идемпотентный ключ — время клиента и сервера» проверяется на эпизоде. Исключения «источник события» записываются до расчёта.
-
Время клиента и сервера. В «источник события» элемент «время клиента и сервера» задаёт границу. Пара «время клиента и сервера — правило связывания событий» проверяется на эпизоде. Исключения «источник события» записываются до расчёта.
-
Правило связывания событий. В «источник события» элемент «правило связывания событий» задаёт границу. Пара «правило связывания событий — пользовательское взаимодействие» проверяется на эпизоде. Исключения «источник события» записываются до расчёта.
Конфликт вокруг «пользовательское взаимодействие» блокирует модель «источник события». Определение «источник события» исправляется до публикации. Усреднение «источник события» не решает смысловой конфликт.
Данные и расчёт
Паспорт «источник события» фиксирует числитель и знаменатель. Субъект «источник события» указывается отдельно. Для «надёжный факт операции и наблюдение пользовательского взаимодействия» задаётся источник времени. Часовая зона «источник события» входит в контракт. Дедупликация «источник события» описывает повторные события.
Ручная сверка «источник события» использует реальные истории. Агрегат «источник события» сравнивается с транзакционным источником. Компоненты «доменная операция», «источник истины» и «идемпотентный ключ» сохраняются отдельно. Разложение «источник события» показывает продуктовый сдвиг или дефект сбора.
Период «источник события» следует естественному циклу. Календарная неделя подходит не всегда. Причина периода «источник события» документируется. Дата пересмотра «источник события» также фиксируется.
Интерпретация и решения
Правила чтения «источник события» записываются заранее. После результата правила «источник события» не переписываются.
-
Нажатие оплаты не означает успешный платёж. В «источник события» правило связано с «пользовательское взаимодействие». Владелец «источник события» указывает действие и срок реакции.
-
Сервер не видит все причины отказа в интерфейсе. В «источник события» правило связано с «доменная операция». Владелец «источник события» указывает действие и срок реакции.
-
Клиентское время не используется как единственный порядок. В «источник события» правило связано с «источник истины». Владелец «источник события» указывает действие и срок реакции.
-
Один доменный факт имеет один ключ. В «источник события» правило связано с «идемпотентный ключ». Владелец «источник события» указывает действие и срок реакции.
-
Ad blockers учитываются при оценке полноты клиента. В «источник события» правило связано с «время клиента и сервера». Владелец «источник события» указывает действие и срок реакции.
Изменение «источник события» сначала проходит техническую проверку. Релиз «источник события» исключается первым. Затем «источник события» сверяется с трафиком и задержкой. Гипотезы «источник события» формулируются после проверки.
Практический пример
Интернет-магазин отправляет checkout_started с браузера и payment_completed с сервера платёжного контура. Оба события несут order_id, но только серверное подтверждение формирует выручку. Клиентские шаги помогают объяснить потери до оплаты.
В примере «источник события» восстанавливаются реальные истории. Поток «источник события» проверяется по «пользовательское взаимодействие». Затем изучаются «источник истины» и «время клиента и сервера». Агрегат «источник события» сверяется с операционной системой.
Итог примера — правило решения «источник события». Правило «источник события» различает эксперимент и исправление данных. Дополнительное исследование назначается отдельно. Дашборд «источник события» остаётся каналом доставки сигнала.
Порядок внедрения
Внедрение «источник события» делится на короткие шаги. Каждый шаг «источник события» оставляет контрольный результат.
-
Разделить намерение и подтверждённый результат. Шаг «разделить намерение и подтверждённый результат» уточняет «пользовательское взаимодействие». В модели «источник события» результат проверяют три роли. Переход «источник события» сохраняется в журнале.
-
Назначить серверные факты для транзакций. Шаг «назначить серверные факты для транзакций» уточняет «доменная операция». В модели «источник события» результат проверяют три роли. Переход «источник события» сохраняется в журнале.
-
Оставить клиенту контекст поведения. Шаг «оставить клиенту контекст поведения» уточняет «источник истины». В модели «источник события» результат проверяют три роли. Переход «источник события» сохраняется в журнале.
-
Добавить correlation_id. Шаг «добавить correlation_id» уточняет «идемпотентный ключ». В модели «источник события» результат проверяют три роли. Переход «источник события» сохраняется в журнале.
-
Дедуплицировать повторные отправки. Шаг «дедуплицировать повторные отправки» уточняет «время клиента и сервера». В модели «источник события» результат проверяют три роли. Переход «источник события» сохраняется в журнале.
-
Сверять расхождения между потоками. Шаг «сверять расхождения между потоками» уточняет «правило связывания событий». В модели «источник события» результат проверяют три роли. Переход «источник события» сохраняется в журнале.
Первый расчёт «источник события» повторяется независимым запросом. Расхождение «источник события» разбирается по фильтрам. Время «источник события» и идентификаторы сверяются далее. Версии «источник события» проверяются отдельно.
Критерии качества
Определение «источник события» готово при следующих условиях:
-
Для каждого события указан источник. Критерий «для каждого события указан источник» проверяет «пользовательское взаимодействие». Подтверждение «источник события» хранится запросом или событием.
-
Доменный результат подтверждается сервером. Критерий «доменный результат подтверждается сервером» проверяет «доменная операция». Подтверждение «источник события» хранится запросом или событием.
-
Потоки связываются устойчивым ключом. Критерий «потоки связываются устойчивым ключом» проверяет «источник истины». Подтверждение «источник события» хранится запросом или событием.
-
Повторы безопасно дедуплицируются. Критерий «повторы безопасно дедуплицируются» проверяет «идемпотентный ключ». Подтверждение «источник события» хранится запросом или событием.
-
Разница времени измеряется. Критерий «разница времени измеряется» проверяет «время клиента и сервера». Подтверждение «источник события» хранится запросом или событием.
-
Известна доля потерянных клиентских событий. Критерий «известна доля потерянных клиентских событий» проверяет «правило связывания событий». Подтверждение «источник события» хранится запросом или событием.
Критерии «источник события» оцениваются совместно. Формула «источник события» не исправляет плохие данные. Точный поток «источник события» бесполезен без решения.
Ограничения применимости
Перед публикацией «источник события» укажите ограничения:
-
Серверный поток может иметь задержку. Ограничение «серверный поток может иметь задержку» меняет вывод «источник события». В ответ добавляется «доменная операция» или качественное исследование.
-
Офлайн-клиенты отправляют события позже. Ограничение «офлайн-клиенты отправляют события позже» меняет вывод «источник события». В ответ добавляется «источник истины» или качественное исследование.
-
Внешний провайдер ограничивает детали. Ограничение «внешний провайдер ограничивает детали» меняет вывод «источник события». В ответ добавляется «идемпотентный ключ» или качественное исследование.
-
Клиентский контекст зависит от согласия и блокировщиков. Ограничение «клиентский контекст зависит от согласия и блокировщиков» меняет вывод «источник события». В ответ добавляется «время клиента и сервера» или качественное исследование.
-
Двойной сбор увеличивает сложность контроля. Ограничение «двойной сбор увеличивает сложность контроля» меняет вывод «источник события». В ответ добавляется «правило связывания событий» или качественное исследование.
Крупное ограничение отменяет общий итог «источник события». Несколько представлений «источник события» честнее одного числа. Ложная определённость «источник события» опаснее сложности.
Вывод
Практика «источник события» начинается с единицы «надёжный факт операции и наблюдение пользовательского взаимодействия». Затем «источник события» связывает формулу, события и проверки. Реакция «источник события» назначается владельцу. Ручная сверка предшествует автоматизации.
Минимум «источник события»: ответить на вопрос «как разделить ответственность между клиентом и сервером с учётом полноты, задержки и доверия к источнику». Далее проверяется формула «клиент фиксирует взаимодействие и контекст интерфейса; сервер подтверждает доменный результат и состояние транзакции». Ограничения «источник события» записываются до регулярного review.
