На вход сервису поступают обновления документов.
```
message TDocument {
string Url = 1; // URL документа, его уникальный идентификатор
uint64 PubDate = 2; // время заявляемой публикации документа
uint64 FetchTime = 3; // время получения данного обновления документа, может рассматриваться как идентификатор версии. Пара (Url, FetchTime) уникальна.
string Text = 4; // текст документа
uint64 FirstFetchTime = 5; // изначально отсутствует, необходимо заполнить
}
```
Документы могут поступать в произвольном порядке (не в том, как они обновлялись), также возможно дублирование отдельных сообщений.
Необходимо на выходе формировать такие же сообщения, но с исправленными отдельными полями по следующим правилам (всё нижеуказанное - для группы документов с совпадающим полем Url):
- Поля Text и FetchTime должны быть такими, какими были в документе с наибольшим FetchTime, полученным на данный момент.
- Поле PubDate должно быть таким, каким было у сообщения с наименьшим FetchTime.
- Поле FirstFetchTime должно быть равно минимальному значению FetchTime.
Интерфейс в коде можно реализовать таким:
```
type Processor interface {
Process(d *Document) (*Document, error)
}
```
Данный код будет работать в сервисе, читающим входные сообщения из очереди сообщений (Kafka или подобное), и записывающем результат также в очередь. Если Process возвращает `nil` - то в очередь ничего не пишется.
БД можно описать интерфейсами (при необходимости использования) с пояснениями (может примерным sql) для понимания, какая логика скрывается за интерфейсом и почему, любые текстовые пояснения приветствуются.
Код должен быть готов к работе в `боевой` среде на столько, на сколько возможно (учтено масштабирование, синхронизация и т.п., если такое возможно).
Тесты так же приветствуются.
В поле ответа вставь ссылку на репозиторий GitHub.