1. Цель проекта

Создать облачный сервис (веб-приложение + облачная база данных), который позволит:

1. Надёжно и безопасно хранить большой объём данных о контактах (имена, телефоны, города, описания сегментов и др.).
2. Предоставлять функционал импорта и экспорта в различных форматах (CSV, XLS, TXT).
3. Создавать и редактировать пользовательские (кастомные) поля в базе (текстовые или выпадающие списки).
4. Фильтровать данные по любому полю, включая поиск дублирующихся значений и обработку номеров телефонов.
5. Гарантировать высокую производительность и возможность масштабирования (от 2 млн записей сейчас, до 10+ млн в будущем).
6. Обеспечивать высокую степень безопасности (разграничение прав доступа, защита данных).

2. Общая архитектура решения

1. Клиентская часть (Front-end)
   • Веб-интерфейс, доступный через браузер.
   • Рекомендуется использовать современные фреймворки (React, Vue.js, Angular) для удобного UI/UX, либо чистый HTML/CSS/JS в зависимости от команды разработки.
   • Основной функционал на фронт-энде:
     • Авторизация и аутентификация пользователя.
     • Интерфейс для загрузки/выгрузки файлов (CSV/XLS/TXT).
     • Формы для создания/редактирования кастомных полей (текст/список).
     • Фильтры и сортировки по всем полям.
     • Отображение статистики (количество уникальных телефонов, наличие дубликатов и т. д.).
     • Просмотр списка контактов с пагинацией (учитывая большой объём данных).
2. Серверная часть (Back-end)
   • REST API (или GraphQL, в зависимости от предпочтений) для взаимодействия клиента с базой.
   • Обработка файлов импорта/экспорта на стороне сервера.
   • Логика по созданию, чтению, обновлению и удалению (CRUD) записей контактов, а также логика фильтров и поиска.
   • Модуль, отвечающий за нормализацию телефонных номеров (приведение к единому формату).
   • Модуль, отвечающий за поиск и обработку дубликатов (например, повторные номера телефонов).
   • Модуль безопасности: аутентификация, авторизация, шифрование конфиденциальной информации.
3. База данных
   • Реляционная БД (MySQL, PostgreSQL) или NoSQL (MongoDB) — выбор зависит от планируемого характера запросов и структуры данных. Если контакты в основном имеют одинаковую структуру и требуется сложная фильтрация и поиск, то предпочтительнее реляционная БД с правильно настроенными индексами. Если структура записей предполагает гибкие (динамические) поля, можно рассмотреть NoSQL-хранилище.
   • Необходимы оптимизации и индексы по основным полям (телефон, имя, город, кастомные поля и т. д.).
   • Масштабирование и отказоустойчивость (бэкапы, репликация).
4. Хостинг и инфраструктура
   • Облачные сервисы (AWS, GCP, Azure или аналоги):
     • Выделенная виртуальная машина или контейнер (Docker) для Back-end.
     • Managed-сервисы (Amazon RDS, CloudSQL, Azure SQL и т. п.) для базы данных.
   • Обеспечение вертикального и горизонтального масштабирования в зависимости от нагрузки.

3. Функциональные требования

3.1. Загрузка и выгрузка данных

1. Импорт
   • Форматы файлов: CSV, XLS, TXT.
   • Пошаговый процесс импорта:
     1. Загрузка файла в интерфейсе.
     2. Предварительный просмотр (optional) и маппинг столбцов файла с соответствующими полями в базе.
     3. Обработка и сохранение в БД.
   • Возможность добавлять новые поля «на лету», если в импортируемом файле есть новые столбцы, которые нужно сохранить (в случае гибкой структуры данных).
   • Обработка больших файлов (до нескольких сотен мегабайт). Возможно, потребуется фоновая асинхронная загрузка с уведомлением пользователя по завершении (через веб-сокеты или e-mail-уведомления).
2. Экспорт
   • Форматы файлов: CSV, XLS, TXT.
   • Выбор, какие поля выгружать (все или выбранные).
   • Возможность экспортировать результат фильтрации (например, выгрузить только контакты из определённого города или сегмента).

3.2. Работа с контактами и кастомными полями