При таком решении поля объекта становятся публичными и надо договориться в команде не злоупотреблять этим.
А почему мы должны делать поля публичными? Таким образом мы нарушаем принцип сокрытия данных, соответсвенно нашей инкапсуляции поведения грош цена. Теперь мы знаем из чего состоит заказ и как он устроен внутри. Почему не закрыть эти данные например так?
type OrderData struct {
Id string
Status string
TrackId string
CreatedAt time.Time
UpdatedAt time.Time
}
type Order struct {
data OrderData
delivery deliveryClient
}
func NewOrder(data OrderData, delivery deliveryClient) *Order {
return &Order{
data: data,
delivery: delivery,
}
}
Тогда непонятно по какому времени. Если мы возьмем условно минуту, то каждую минуту с каждой реплики мы будем ходить в хранилище за миллионами или даже десятками миллионов записей, хотя возможно этого не надо было делать, мы создаем рабочую нагрузку на ровном месте. Вполне допустимо инвалидировать по времени, если например мы давно не получали сообщения о синхронизации, получится совмещенный вариант.
Да, это сетевые запросы, но они никак не влияют на производительность сервиса, так суть данного паттерна - не гонять супер много данных через кафку, а условно "посигналить" всем остальным что нужно обновить кеш. Для этого достаточно просто пустого сообщения, в самом простом случае, ну или передать просто пару ключей в случаях сложнее. Так же go позволяет писать конкурентный код, это так-же можно использовать в случае записи больших сообщений параллельно каких-то сетевых операций сервиса. Так же есть возможность асинхронной записи, но это уже риск потерять сообщения.
Например передача большого количества текста по сети, между кешом и репликой, это может накладывать серьезный отпечаток на производительности.
Если мы говорим о синхронности в любой момент времени, то конечно тут возникает куча проблем. Но возможны задачи которые не имеют жесткий требований к синхронизации данных, даже задержка в 30 секунд и более для нас не критична (например это может быть какое-то длинное описание товара).
Но замечание справедливое, отмечу этот момент в тексте.
В целом, паттерн из статьи не позиционируется как серебряная пуля для любых задач, связанных с синхронизацией и доступом к актуальным данным.Конечно есть задачи с более жесткими требованиями, и они требуют совершенно других подходов.
Скорее речь о том, что с помощью этого подхода мы совсем отказываемся от состояния невалидного кеша, ну или продолжительность этого состояния ничтожно мала.
Да, важное уточнение, не усложнять новыми компонентами на фоне уже сложившейся архитектуры, где присутствует kafka. Например в компании где работаю я, так и вышло.
При таком решении поля объекта становятся публичными и надо договориться в команде не злоупотреблять этим.А почему мы должны делать поля публичными? Таким образом мы нарушаем принцип сокрытия данных, соответсвенно нашей инкапсуляции поведения грош цена. Теперь мы знаем из чего состоит заказ и как он устроен внутри. Почему не закрыть эти данные например так?
Тогда непонятно по какому времени. Если мы возьмем условно минуту, то каждую минуту с каждой реплики мы будем ходить в хранилище за миллионами или даже десятками миллионов записей, хотя возможно этого не надо было делать, мы создаем рабочую нагрузку на ровном месте. Вполне допустимо инвалидировать по времени, если например мы давно не получали сообщения о синхронизации, получится совмещенный вариант.
Да, это сетевые запросы, но они никак не влияют на производительность сервиса, так суть данного паттерна - не гонять супер много данных через кафку, а условно "посигналить" всем остальным что нужно обновить кеш. Для этого достаточно просто пустого сообщения, в самом простом случае, ну или передать просто пару ключей в случаях сложнее. Так же go позволяет писать конкурентный код, это так-же можно использовать в случае записи больших сообщений параллельно каких-то сетевых операций сервиса. Так же есть возможность асинхронной записи, но это уже риск потерять сообщения.
Например передача большого количества текста по сети, между кешом и репликой, это может накладывать серьезный отпечаток на производительности.
Если мы говорим о синхронности в любой момент времени, то конечно тут возникает куча проблем. Но возможны задачи которые не имеют жесткий требований к синхронизации данных, даже задержка в 30 секунд и более для нас не критична (например это может быть какое-то длинное описание товара).
Но замечание справедливое, отмечу этот момент в тексте.
В целом, паттерн из статьи не позиционируется как серебряная пуля для любых задач, связанных с синхронизацией и доступом к актуальным данным.Конечно есть задачи с более жесткими требованиями, и они требуют совершенно других подходов.
Скорее речь о том, что с помощью этого подхода мы совсем отказываемся от состояния невалидного кеша, ну или продолжительность этого состояния ничтожно мала.
Да, важное уточнение, не усложнять новыми компонентами на фоне уже сложившейся архитектуры, где присутствует kafka. Например в компании где работаю я, так и вышло.