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

Что проверяют

Умеете ли вы рассуждать о данных и рисках, а не только о тест-кейсах. Для тестировщика такой вопрос обычно про in-memory заглушку сервиса для автотестов или про то, что сломается, если команда решила хранить всё в памяти. Следом спрашивают: а как вы это протестируете?

Как отвечать

Сначала уточните условия: сколько клиентов и счетов, нужны ли данные после перезапуска, есть ли параллельные операции. От ответов зависит всё остальное. Затем дайте каркас, например на Go, если автотесты у команды на нём:

• структура: map[ClientID]*Client, у клиента map[AccountID]*Account, плюс отдельный индекс map[AccountID]ClientID для поиска клиента по счёту;
• деньги: int64 в копейках или decimal-тип, но не float64, иначе копейки теряются на округлении;
• конкурентность: map в Go небезопасна при параллельной записи, нужен sync.RWMutex или шардирование по ID. Перевод блокирует оба счёта в фиксированном порядке, иначе возможен deadlock;
• объём: прикиньте на пальцах. Миллион клиентов по пять счетов при паре сотен байт на счёт уже порядка гигабайта, и сборщик мусора обходит все указатели в куче;
• сохранность: без базы данные живут до перезапуска. Если терять их нельзя, нужен журнал операций в файл и периодический снимок.

Затем покажите взгляд тестировщика. Прогон с go test -race ловит гонки. Инвариант «сумма всех балансов после серии переводов не изменилась» проверяется под параллельной нагрузкой. Отдельно нужны тесты на перезапуск, на рост памяти через pprof и на поведение при нехватке памяти, когда контейнер убивает OOM killer.

Где спотыкаются

Отвечают одной фразой «положу в HashMap» и не спрашивают про объём, параллельный доступ и перезапуск. Именно эти вопросы и проверяют.

Предлагают удалять «неактивных» клиентов, чтобы сэкономить память. Для финансовых данных это потеря информации, а не оптимизация.

Не называют способ проверки. Для QA-позиции решение без плана тестирования выглядит неполным: нужны гонки, инварианты и сценарии отказа.