Ну во-первых, у тебя четыре задачи.
1. Фронт. На каких платформах планируешь клиенты? Веб-клиент позволяет охватить много устройств, но он также может оказаться наиболее прожорливым по ресурсам. Если планируешь отдельные клиенты под отдельные платформы - надо смотреть отдельно под каждую платформу. Сразу исходи из того, что универсального решения не будет.
Под веб, разумеется, надо учить веб-стэк - как вообще работает HTTP, основы HTML+JS+CSS, скорее всего, придётся ознакомиться с каким-то JS-фреймворком, потому что на голом JS удобно писать только достаточно простой клиент. Стоит также заглянуть в сторону вебсокетов.
2. Протокол обмена. Их много разных - и это если не изобретать свой велосипед. Текстовые протоколы проще в отладке. Бинарные - компактнее (экономит трафик). Некоторые протоколы работают строго в рамках модели запрос клиента -ответ сервера (как HTTP), некоторые позволяют любому концу соединения проявлять инициативу. В твоей задаче запрос-ответ будет работать так себе. Читай про существующие универсальные протоколы обмена, такие как JSON-RPC или gRPC. Загляни в сторону REST. Да хоть старичка IRC посмотри. Важны моменты: многословность протокола (сколько надо передать байт по сети на N символов текста? А на N байт бинарного контента?), ограничения на передаваемые данные (например, можно ли передавать произвольные бинарные данные?), наличие библиотек для работы с протоколом, устойчивость к разрывам соединения, и т.д.
3. Бэк (сервер). В твоей задаче бэку лучше быть событийно-ориентированным, поэтому надо понимать суть событийно-ориентированной архитектуры. Соответственно, исходя из выбора протокола, выбираешь язык, для которого есть библиотеки под этот протокол, и в идеале который тебе знаком. Разбираешься, как организуется работа с этими библиотеками.
Продумываешь, какими сущностями ты будешь оперировать. Например, у тебя будут только чаты 1 на 1, или будут групповые чаты? А если групповые чаты, они будут одноранговые, или будут иметь структуру, типа серверов в Дискорде? Затем продумываешь, как ты это будешь хранить в базе данных.
Да, с базами данных надо быть знакомым.
Ну и задача №0, которую я описываю последней. Определи, под какую нишу ты делаешь свой мессенджер, кто будет им пользоваться, что для них будет важно? Условно, мессенджер, который предназначен для координации действий группы людей на реальной местности, это не то же, что месседжер, предназначенный для общения внутри корпорации, и не то же, что мессенджер, предназначенный для домовой/общажной локалки, где может не быть одного выделенного сервера.
В частности, важным вопросом будет структура сети. Централизованная, как Телеграм? "Лес", где может быть несколько серверов, но они не вазимодействуют? Федеративная, как e-mail или matrix, где можно поднять свой сервер, и взаимодействовать с клиентами других серверов? Одноранговая (P2P), как Tox? Это сильно повлияет и на целевую аудиторию, и на устройство протокола.
