InoMono

Если вы про российское законодательство, то у нас разрешено с целью пародирования.
Если про американское - вообще запрещено.

Различайте три автора:
Автор музыки
Автор текста
Автор исполнения

От того, что вы стали автором чего то одного из 3-х вовсе не означает, что автоматические получаете права на оставшиеся 2/3.

Насчет других каверов:

1) Недосмотр. Их удалят
2) Да, они брали разрешение
3) Оригинал находится в "public domain"

Вы ошибаетесь:
Досканально знать язык не нужно. Хорошо в нем ориентироватся - да. На остальное - есть справочники. Тебе нужно ориентироваться, чтобы знать где именно искать.

Вторая ваша ошибка:
Говнокодерство к уровню знания языка отношения не имеет.
Да, самое никакующее знание языка будет давать говнокодерство.
Но при этом и самое отличное знание языка от говнокодерства ничуть тебя не гарантирует.

Не говнокодить - это знать методологии/паттерны/приемы, а не язык. И грамотно и уместно применять их - а это вообще не знания даже, а навыки.

Более того: с отличной практикой по методологиям/паттернам/приемам - у вам больше шансов не говнокодить даже на начальном этапе изучения языка, пока вы его едва-едва знаете.

Чтобы не быть г*внокодером

Кроме отрицательной эмоциональной окраски - что тут такого.
Даже выдающиеся программисты говнокодят, если проект одноразовый или сроки жмут.
Это нормально.

Другое дело, что есть и такие которые всегда говнокодят и иначе не могут.

Вполне себе любая развитая современная РСУБД годится для этой задачи.
MySQL, PostgreSQL...

А по мере роста нагрузки - тут не выбором СУБД нужно заморачиваться, а MQ-сервер ставить. Он гораздо легче сравиться с бешенными нагрузками.

Как вариант - Queue на базе Tarantool, например. Я даже не знаю что вы там должны такое сделать, чтобы заткнуть его производительность. При условии того, что на сервере достаточно много оперативной памяти.

Из самого критично подозрительного - полнотекстовый поиск.
Впрочем, полагаю, что полнотекстового поиска средствами MySQL или PostgreSQL вплоне хватит.

Если уж делать прям таки серьезный чат типа Slack, то для полнотекстового поиска я бы вообще отдельную специализированную БД держал бы. Например, SphinxSearch.

Но, для начала, возможностей PostgreSQL или MySQL будет вполне достаточно.

Что до Mongo... Если вам не нужна репликация без консистентности. Зато быстрая...
Так вот если вам не нужна такая репликация, то Монга вам не нужна.

РСУБД будут существенно быстрее.

Вот ежели вы планируете заводить ваш чат в кластер, когда одного сервера вам не хватит, то тут да, тут РСУБД не лучший выбор. Тут бы я рекомендовал как раз Монгу.
Но опять таки кластер серверов для чата вы без MQ не сделайте.

Вывод:

Начните с обычной РСУБД.
Как начнутся затыки - рассмотрите MQ
Как начнется рост до масштаба планеты - рассматрите Монгу.

Вся система работает с бд MySQL - InnoDB, сообщения пишутся в бд при каждой отправке (INSERT), пока сервис еще не запущен, сообщений мало (только мои тестовые) все работает шустро, но вот когда запущу и количество сообщений перевалит за несколько миллионов, что будет тогда с моей бд? Начнутся жесткие тормоза при select и insert?

Вам никто не мешает это проверить.
Сгенерируйте миллион случайных сообщений.

При грамотном использовании индексов - ровным счетом никаких проблем ни на миллионах ни на миллиардах записей.

Вот как раз что именно для успешной соц. сети и смысла нет сразу.
Имеет смысл докупать мощности по мере роста сети.

Ибо разница очень и очень велика на начальном этапе и то что будет через год-два. Ну это если проект "взлетит" конечно. Это я в предположении, что инвесторов не интересует невзлетающие проекты. Значит, рассчитываем на то, что н взлетит.

Кроме того, если вы разработчики - то вам самим следует это знать.

Если вы способны создать крайне эффективный проект, то:

StackOverflow буквально несколько лет назад уже был известным и раскрученным на весь мир проектом. Наверное самым известным среди проектов подобного рода. И все миллионы пользователей, которые активно пишет на нем и активно читают - обслуживало всего навсего 2 сервера, под фронтенд и СУБД (не считая резервных/репликационных, само собой). Это были сервера на неплохом железе, но не дорогие. Поищите в сети, есть подробности.

Вдумайтесь, весь мир, миллионы посетителей, активные пользователи, нагружающие СУБД операции поиска и записи. И всего пара серверов.

В то же время мне доводилось видеть и прямо таки обратные примеры. Когда примерно такое же железо и пару тысяч посетителей в день не может вытянуть.... Ну говнокодеры делали, чего взять.

---------

Оцените масштаб и необходимая скорость реагирования на рост.

1. Если вы прям серьезно хотите, то вам в микросервисную архитектуру (Kubernetes вам в помощь) и в облака.
2. Однако я полагаю, что первые пару лет посетителей не будет много. Поэтому начать можно вполне себе с VDS просто переключая тариф на постарше и постарше. Это копейки. Единственно, что я сразу бы вынес картинки/видео в облака, это очень удобно и не заботишься ни о месте на диске не о конфигурировании ПО. Использовать для этого специализированные сервисы: Openstack Swift (много хостеров), Google Storage, AWS S3 и т.п. При вынесении подобной тяжелой вещи с сервера - движок будет совершенно не требовательным.

---------

Вам тут в соседнем посте правильно ответили:

Стоимость разработки и раскрутки этой хрени огромна на фоне стоимости серверов.
Сервера - копейки стоят.

Если инвестор начитает уже и тут докапываться, то, очевидно, что команда будет пахать за копейки.

А так то расходы на команду в неделю могут быть больше чем за все сервера за год.
В течение первых лет пяти раскрутки.

И только по мере стабилизации сети, меньших объемов работ, но большей масштабности серверов - стоимость серверов будет превышать стоимость услуг людей.

---------

Если бы я начал этот проект сам:
то заложил бы на первый год сумму 6000 рублей в месяц на два сервера (основной и репликацию, движок и БД на одной машине, картинки/видео на отдельном облачном сервисе). Причем это VDS, а не выделенный сервер.
На второй год 40 000 рублей в месяц (два кластера по 3 сервера в каждом).
Начиная с третьего года ушел бы в облака.
Там, полагаю, ценник был бы на уровне 30 000 - 60 000 рублей в месяц первое время.
С четвертого года рассчитывал бы на 90 000 - 180 000 расходов в месяц.
После этого начал бы подумывать, не уйти ли с облаков на свою инфраструктуру.

Но это про мою гипотетическую архитектуру.
Возможно у вас другая цель и другая архитектура.

---------------

Как считать:

Прикидываем количество пользователей.
Прикидываем объемы генерируемого ими контента (причем это и фото и видео и сообщения и технические логи тоже не забыть, их немало)
Умножаем на 3 (в серьезных системах нужно двойное реплицирование: оригинал и 2 копии)
И добавляем еще 1 копию под разработку и "ранний доступ к бете", сплит-тестирование и пр.
Дальше тут уже зависит от вашей архитектуры. Как я уже писал микросервисная архитектура хороша для взрывного роста, но довольно требовательна при небольшой нагрузе. Если вы прям не на 100% уверены в взрывном росте - лучше от нее отказаться, она и в разработке и в поддержке геморнее. Но зато масштабируется классно, это у нее не отнять.
Дальше, если это будет на весь мир - нужно подумать насчет пары-тройки кластеров разной географии.

-----------------

Если у вас нет информации об количестве пользователей и объемах генерируемого ими контента - говорить тут конкретику невозможно.