Алексей

Если используете Докер и прямо хотите докеризировать с мастабированием, то используйте сеть докера для связи между контейнерами для начала.
У вас должно быть 1 контейнер с nginx наружу (80 порт и/или 443), 1 контейнер для сборки приложения VueJS, 1 контейнер для работы с PHP-проектом и дальше что там у вас, по контейнеру для СУБД (1 Redis, 1 RabbitMQ, 1 MySQL). Каждому контейнеру дайте нормальное уникальное имя, чтобы можно было их подключать друг к другу по dns-имени. Наружу порт только для nginx давайте, он будет за все отвечать.
1. Контейнер с nginx отдает статику, собранную из приложения VueJS. Собственно все как обычно - собрали dist, из него и отдаете. В идеале собирать в отдельном контейнере c NodeJS, а полученные данные из dist копировать в какой-нибудь volume наверное и подключить его к контейнеру с Nginx. Это можно делать на уровне файлов docker-compose и автоматизировать при сборке проекта. Этот же volume можно подключить и к контейнеру с backend-api, тогда оно сможет работать с файлами, которые загрузили.
2. Из первого контейнера с nginx по upstream отдавать backend-api, который будет обращаться к еще одному контейнеру, где крутится PHP и собственно ваш symphony проект. Наружу этот контейнер не пускайте, подключайте к первому контейнеру через имя. Таким образом вы сможете запустить несколько контейнеров с api, указав все их dns-имена в разделе нужного upstream. Уже получаете горизонтальную масштабируемость, эти контейнеры потом можно запускать вообще на разных серверах, соединив их, например при помощи Docker Swarm или в Kubernetes. Опять же все можно оформить на уровне файлов конфигурации Docker Compose, там не сложно, достаточно почитать документацию.
3. Все контейнеры с СУБД запускайте тоже в отдельных контейнерах, где нужно - создавайте volume для хранения БД. Их тоже наружу не пускайте, биндите на уровне Docker с контейнером (ами) с backend-api. Вообще если предполагается серьезная нагрузка, то СУБД вообще рекомендуют запускать не в контейнерах, но тогда чуть сложнее автоматизировать привязку и масштабирование будет. Для начала можно и в контейнерах, когда она придет, эта нагрузка то... Тем более контенеры с СУБД тоже можно в нескольких экземплярах запускать, между ними репликацию сделать или вообще шардинг. Все это можно наверное во всех описанных БД сделать, но с шардингом помучаться конечно придется. Репликация проще всего. А уже к ним подключаться из backend-api по dns-именам, как настроите.

Как то так.

Самые бескомпромиссные варианты на скорость чтения и записи - база данных Redis и подобные ей (Aerospike, Tarantool). Данные хранятся в памяти, их чтение и запись максимально быстрая. Эти базы NoSQL в виде ключ-значение, то собственно всю вашу задачу покрывает с лихвой. Ключ = номер телефона, значение = описание. Можно чуть усложнить базу данных , чуть изучив структуры даннных Redis - при желании конечно.
Единственное ограничение в случае Redis - количество ОЗУ на сервере. Под 1.5 млн записей по 200 байт понадобится больше 700МБ. Соответственно с ростом количества записей потребление памяти будет расти пропорционально. Впрочем сейчас можно найти недорогие сервера с большим количеством памяти, не то, что раньше. Потребление памяти можно распределить, используя кластерное решение, которые выглядит вроде интересным, но если честно - не очень удобным. По крайней мере не текущем этапе разработки. Надежность такой базы тоже можно увеличить, если сделать репликацию на другой сервер, где данные будут постоянно записываться на диск в режиме AOF - тогда потерять их будет сложнее, а работа с базой на мастере не будет замедлена небыстрыми дисковыми операциями. Можно этот AOF сделать и на одном сервере, если SSD - то нагрузка будет практически незаметная.
Если есть время и достаточно опыта в разработке - можно разобраться в аналогах, у которых ограничение в ОЗУ не так сказывается. Тот же Aerospike например оптимизирован под работу на SSD, а Tarantool может хранить в себе гораздо больше данных, чем позволяет объем ОЗУ, без особых потерь производительности (так заявляют).
Также у облачных сервисов Amazon / Azure / Google есть свои базы для key-value, можете изучить их стоимость, возможно вас устроит.

Теоретически вы так же можете использовать MySQL или PostgreSQL, структура не настолько сложная у вас, чтобы эти СУБД не справлялись с ними. Но их производительность все будет уступать Redis на порядок.