Дмитрий Энтелис

Есть специальные сервисы, поставляющие спортивную data (одна из таких контор на моей памяти еще лет 5 назад привлекла сотни миллионов инвестиций) и статистику. Нанимают агентов во всех странах, по некоторым событиям просто мониторят прямые трансляции. Крупные букмекеры нанимают специально людей, которые прям на стадион на события ходят и оттуда сообщают, потому как задержка даже в 1 секунду для букмекера/биржы может обернуться миллионными потерями из-за послегольщиков.

devstickers.com

Диска, конечно, хотелось бы побольше. Но вообще, такие объемы при грамотных индексах не проблема от слова совсем. В крайнем случае, можете по крону раз в неделю архивировать записи и чистить таблицу, если будет какая-то чувствительная просадка производительности.

Средствами python

Гггг))) Как бы с первого взгляда и одно и то же, но не совсем.
Если первый вариант юзать на практике - далеко не всегда ваш ".button" будет совпадать с тем, что находится в таргете. Например на кнопке иконка/рисунок/etc. Поэтому вам придется дописывать специализированный костылеподобный изворот типа:

if ($(e.target).closest('.button').length){
	//....
	e.stopPropagation();
}

что само по себе уже не совсем тоже самое, как предпогалолась в вопросе.
К тому же, не будет возможности использовать .trigger() для .button
Ну и не известно сколько еще потом по вылазит глюков, требующих, чтоб и их подперли чем-то...
В итоге получится явно не быстрее и не стабильней чем в либе. Там как ни как сидят, почесывая башни изо дня в день, думая как еще оптимизировать и стабилизировать работу методов. Версий то вон уже сколько вышло.

UPD

Просто когда жму Event Listeners в chrome - там у каждого элемента оочень много listener'ов

Во втором варианте слушатель вешается не на кнопку, а на документ. Видимо у вас просто установлен чекбокс на "Ancestors".

Ну а если вам взбредет в голову все таки писать свою реализацию делегирования, то в лучшем случае, как мне кажется, вы придёте к оригинальной реализации метода jq.

Итак, что вам нужно. Предполагается, что у вас есть табицы user и group.

Таблица со списом чатов

chat
	id - идентификатор чата
	name - название чата (тема обсуждения)
	user_id - идентификатор  пользователя, который создал чат (необязательно)

Список участников чата

roster
	chat_id - идентификатор чата
	user_id - идентификатор пользователя
	group_id - ид группы, если пользователь пишет от имени группы или NULL, если от пользователя (можно даже держать 2 записи, где group_id = null и где нет)

Список сообщений

messages
	id - идентификатор сообщения
	chat_id - идентификатор чата
	user_id - ид пользователя
	group_id - ид группы, если сообщение отправлено от имени группы или NULL, если от пользователя
	text - текст сообщения

Статусы сообщений

message_status
	message_id - идентификатор сообщения
	user_id - идентификатор пользователя
	read - прочтено или нет
	notified - отправлено уведомление о сообщении или нет

Итак, как это работает.
Круг, в котором общаются пользователи называется чатом (chat).
Кто находится в чате определяется через ростер (roster). Ростер может не быть показан в интерфейсе.
Кто кого приглашает в чат определяется через бизнес-логику приложения.

В данной схеме сценарий "Пользователь2 пишет в Группа1" выглядит так.
Создается чат, далее в ростер добавляются П2 и Г1. Далее просто создается сообщение от имени П2. Через бизнес-логику находится владелец Г1 и ему отправляется уведомление.