1. Проектируем не контейнер, а работу с данными

Вопрос «массив или Map?» появляется слишком поздно. Раньше него должны появиться операции: добавить событие, найти по id, взять следующее задание, удалить просроченное, показать первые 50 элементов, восстановить порядок. У каждой операции есть частота, размер данных и требование к порядку.

Например, UI-лента может часто получать новые элементы и редко удалять из середины. Очередь воркеров часто забирает один элемент с головы. Кэш почти всегда отвечает на поиск по ключу. У этих трёх задач похожее слово «список», но разные рабочие операции.

2. Инвариант - то, что нельзя потерять

Инвариант делает структуру полезной. У очереди порядок FIFO: первым забирают того, кто пришёл раньше. У множества нет дубликатов. У heap минимальная или максимальная задача доступна наверху. У индекса записи упорядочены по ключу согласно правилам структуры.

Если инвариант не назван, код легко превращает структуру в просто массив объектов. Тогда добавляются линейные поиски, случайные сортировки и флаги, которые спорят друг с другом.

3. Big O - модель, а не секундомер

O(1), O(log n) и O(n) помогают оценить рост работы при росте n. Они не обещают одинаковое время на любом железе, не учитывают сеть и не заменяют профилирование. Но они хорошо ловят ошибку масштаба: если в обработчике каждого сообщения ты проходишь весь массив пользователей, стоимость одного события растёт вместе с базой.

Отдельно помни про амортизированную стоимость. Динамический массив обычно быстро добавляет элемент в конец, но иногда расширяет буфер и копирует элементы. Редкая дорогая операция размазывается по серии дешёвых добавлений.

Практика: мини-паспорт структуры

1. Выбери одну сущность из текущего проекта: уведомление, заказ, документ или websocket-сообщение.
2. Выпиши пять операций и отсортируй их по частоте.
3. Назови два инварианта: порядок, уникальность, лимит, приоритет или связность.
4. Укажи, что изменится при 10 000 элементах или 100 событиях в секунду.