Вопрос по тестовому заданию, масштабируемый сервис?

Question

[viig]

Здравствуйте. Такое вот тестовое задание

Create a service that collect data from cryptocompare.com using its API and stores it in a database (MySQL/PostgreSQL/Mongo)
Example API request: GET https://min-api.cryptocompare.com/data/pricemultif...

REQUIREMENTS:
1. Currency pairs must be configurable.
2. Database parameters must be configurable.
3. Service must store data in database by a scheduler.
4. If cryptocompare's api is not accessible service must serve data from its database.
5. API should accept as many fsyms/tsyms in one request as possible (ex.: GET service/price?fsyms=BTC,LINK,MKR&tsyms=USD,EUR,ETH,LTC should return all pair prices)
6. Data in response must be fresh (realtime). 2-3 minutes discrepancy is ok.
7. Service scalabillity is a plus.

В целом все понятно, но есть момент - что подразумевается под масштабированием, седьмой пункт? Какое тут может быт масштабирование? Запускать несколько копий сервиса который просто опрашивает URL и сохраняет данные в базу, и обслуживает один API роут?
И сохранение в базу по расписанию. Кроме setInterval, какие еще есть решения и в чем их преимущества.

Спасибо.

Comments

[profesor08]

Example API request: GET https://min-api.cryptocompare.com/data/pricemultif...

На этом моменте можно просто сделать точную копию апи сервиса, тупо проксируя запросы и подставляя API ключ xDDD

[viig]

profesor08, кстати да :), но зачем тогда в базу сохранять. Пункты 4 и 6 как-то противоречат друг другу )

[profesor08]

viig, не вижу противоречий, если сервис сдох, то он сдох, но твой должен продолжить работать. Неплохо бы вывести ошибку, что есть проблемы и данные не актуальны.

Answer 1

[insighter]

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

Answer 2

[⚡ Kotobotov ⚡]

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