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

Вообще хороший вопрос для чата pro.kafka

там по-моему нельзя записать в топик сообщение, если оно не соотв. схеме. но это неточно

а это был мой следующий вопрос: про применимость Schema Registry в Event-Driven системах без очереди сообщений

Ну, примерно так же, нельзя отправить событие, если оно не соответствует схеме.

в случае с кафкой я, как понял, кафка просто не примет такое событие. Если посредника нет, то такое решение всё равно придется делать на стороне отправляющего, что собственно можно сделать и без реестра

Сделай простой tlv и в качестве payload уже flatbuffers

Только кластер нельзя расширять

На сколько помню Кафка примет любое сообщение. Она принимает сериализованные бинарные данные. А как они были сериализованы ей без разницы. С schema registry работают сериализатор и десеривлизатор. Schema registry по умолчанию не позволяет залить несовместимую схему

ага, то есть это делается на уровне самого сервиса всё же. и условно мне никто не мешает в топик отправить сообщение с какой-то левой схемой

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

ага, понял теперь, как оно работает. Спасибо

👍

привет коллеги

у нас возник концептуальный спор на тему доступа сотрудников техподдержки к данным обратившегося клиента.
Есть два подхода:
1) создание отдельного специализированного инструмента для тех.поддержки  - "отдельный бэкофис"
2) механизм доступа сотрудника техподдержки напрямую через интерфейс пользователя в ЛК пользвоателя, но с ограниченными правами (только просмотр и то не всё) - общий пользовательский интерфейс, специальная роль доступа

Поделитесь соображениями какие варианты реализации доступа техподдержки к данным клиента вы считаете лучшими?

Думаю, зависит от контекста. Оба варианта равно рабочие.

так только просмотр не запрещает сфоткать))

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

Не знаю, довели до конца реализацию или нет

Какие факторы с моей точки зрения нужно принимать во внимание:
- ИБ
- эффективность службы поддержки
- степень удовлетворенности клиентов (связан с предыдущим пунктом)

У нас есть специализированный бэкофис, в котором есть кнопка "login as", по которой оператор попадает в пользовательский интерфейс.
Просто есть данные, которому пользователю показывать не надо.
И есть потребность поддержки посмотреть "а что там происходит".

The same (в нескольких проектах)