На днях тоже наткнулся на это тестовое задание. Оно было менее лаконичное.
Более полный текст задания
**Задача:** есть приложение с базой клиентов, порядка 10 млн. У всех заполнены данные паспортов, которые могут просрочиться, быть утеряны и т.д. В связи с этим нужна система для проверки валидности этих паспортов на основе данных ФМС.
Задание по сути — создание микросервиса. Не библиотеки, а именно самостоятельного сервиса.
**Требования:** время ответа на запрос 1ms, uptime 99%. Больше требований нет, остальное на своё усмотрение.
Если мы с автором поста решали одно и то же задание, то, на мой взгляд, это решение не полное решение задачи.
В тексте указано, что необходим самостоятельный сервис, который будет отвечать за 1мс. То есть этим сервисом предполагается пользоваться не только в рамках тех 10 млн пользователей. Иначе можно было бы распаковать файл, положить в хэш таблицу, пробежаться по своей базе, сделать проверки и profit.
Чтобы сервис отдавал ответ за 1мс, необходимо не только алгоритм определения валидности продумать, но и остальные расходы. В первую очередь сеть. Если вы развернёте на локальной машине почти любой веб сервер, то самый простой GET запрос с этой же машины будет выполняться больше 1мс. Это связано с тем, что мы неизбежно будем тратить время на тройное рукопожатие. Тем более в предложенном решении предлагается еще и ходить в редис, что по той же причине только удвоит затраты на сеть.
На мой взгляд, в задаче необходимо отказаться от промежуточного веб сервера, реализовав обработку подключений внутри своего сервиса, использовать персистентное HTTP подключение, а данные хранить в памяти процесса. При этом я согласен с автором в части структуры хранения данных.
Задание по сути — создание микросервиса. Не библиотеки, а именно самостоятельного сервиса.
**Требования:** время ответа на запрос 1ms, uptime 99%. Больше требований нет, остальное на своё усмотрение.
Если мы с автором поста решали одно и то же задание, то, на мой взгляд, это решение не полное решение задачи.
В тексте указано, что необходим самостоятельный сервис, который будет отвечать за 1мс. То есть этим сервисом предполагается пользоваться не только в рамках тех 10 млн пользователей. Иначе можно было бы распаковать файл, положить в хэш таблицу, пробежаться по своей базе, сделать проверки и profit.
Чтобы сервис отдавал ответ за 1мс, необходимо не только алгоритм определения валидности продумать, но и остальные расходы. В первую очередь сеть. Если вы развернёте на локальной машине почти любой веб сервер, то самый простой GET запрос с этой же машины будет выполняться больше 1мс. Это связано с тем, что мы неизбежно будем тратить время на тройное рукопожатие. Тем более в предложенном решении предлагается еще и ходить в редис, что по той же причине только удвоит затраты на сеть.
На мой взгляд, в задаче необходимо отказаться от промежуточного веб сервера, реализовав обработку подключений внутри своего сервиса, использовать персистентное HTTP подключение, а данные хранить в памяти процесса. При этом я согласен с автором в части структуры хранения данных.