Redis — это открытое [BSD 3-clause] ПО, реализующее хранение данных типа «ключ-значение» в ОЗУ (преимущественно).
С ключом может быть ассоциировано время жизни, по истечении которого он будет удален.
Значениями могут выступать строки, хэш-таблицы, списки и множества.
Любую модификацию пространства ключей можно отследить через встроенный механизм событий (отключен по умолчанию в угоду производительности).
В дополнение к транзакциям, пользователь может определять новые операции, что будут выполняться атомарно, используя языковые средства LUA 5.1.

Подробно и из первых уст ~ 15 минут

SPL
Концептуальная
Наивный подход
Самое очевидное решение, которое можно придумать: несколько методов доставки (send_vk, send_telegram и т.д.) и один обработчик, который будет вызывать их с нужными аргументами.
Проблема расширяемости
Если мы захотим добавить новый метод доставки, то будем вынуждены модифицировать существующий код, а это — ограничения программной платформы.
Проблема стабильности
Сломался один из методов = сломался весь сервис.
Прикладная проблема
API разных каналов связи значительно отличаются друг от друга в плане взаимодействия. Например, ВКонтакте поддерживает массовые рассылки, но не более чем для сотни пользователей за вызов. Telegram же нет, но при этом разрешает больше вызовов в секунду.
API ВКонтакте работает только через HTTP; у Telegram есть HTTP-шлюз, но он менее стабилен, нежели MTProto и хуже документирован.
Таких различий достаточно много: максимальная длина сообщения, random_id, интерпретация и обработка ошибок и т.д. и т.п.
Как с этим быть?
Было принято решение разделить процесс постановки сообщений в очередь и процессы отправки (далее — курьеры) на организационном уровне, причем так, чтобы первый даже не подозревал о существовании последних и наоборот, а связующим звеном между ними будет выступать Redis.
Непонятно? Закажите покушать!
А пока ждете — позвольте познакомить вас с моей интерпретацией сего благородного действа, начиная с оформления и заканчивая закрытой за курьером дверью.

• Вы нажимаете на большую желтую кнопку «Заказать»;
  
• Яндекс.Еда находит курьера, сообщает выбранные позиции ресторану и возвращает вам номер заказа, дабы разбавить неопределенность ожидания;
  
• Ресторан по завершении готовки обновляет статус заказа и отдает еду курьеру;
  
• Курьер, в свою очередь, отдает еду вам, после чего помечает заказ как выполненный.

Приятного аппетита!
Вернемся к проектированию
Возможно, что приведенная в параграфе ранее модель не вполне соответствует действительности, но именно она легла в основу разработанного решения.
Ассоциирующиеся с номером заказа данные будем называть историей, она позволяет в любой момент времени ответить на следующие вопросы:

• Кто отправил;
  
• Что отправил;
  
• Откуда;
  
• Кому;
  
• Кто и как получил.

История создается вместе с заказом как два отдельных Redis ключа, связанных через суффикс:

Заказ определяет — когда курьеры единожды увидят историю, чтобы, по завершении отправки, соответствующим образом изменить ответ на вопрос “Кто и как получил”.
“Зрение” курьеров работает через подписку на событие DEL ключей по форме delivery:*.
Когда наступает момент доставки, Redis удаляет ключ заказа, после чего курьеры приступают к его обработке.
Так как курьеров несколько — велика вероятность возникновения конкуренции на стадии изменения истории.

Избежать её можно, определив соответствующую операцию атомарно — в Redis это делается через LUA-скриптинг.
Детали реализации будут подробно рассмотрены в следующей главе. Сейчас же важно получить четкое представление о решении в целом с чем может помочь рисунок ниже.

Отслеживание статуса
Клиент может отследить статус доставки через ключ истории, который генерируется отдельным методом API разрабатываемого сервиса перед постановкой сообщения в очередь (как и номер заказа генерируется Яндекс.Едой в самом начале).
После генерации ключа, на него вешается (опционально и тоже отдельным методом) трекер с тайм-аутом, который будет следить за числом изменений истории курьерами (SET события). Только теперь сообщение ставится в очередь.

Если курьер не находит контактов получателей в своем домене — канале связи, то он вызывает искусственное событие SET через команду PUBLISH, тем самым показывая что он “в порядке” и ждать дальше не надо.
Зачем мудрить с событиями в Redis, если есть RabbitMQ и Celery
На то есть как минимум пять объективных причин:

• Redis уже используется другими сервисами Ады, RabbitMQ/Celery — новая зависимость;
  
• Redis нужен нам, в первую очередь, как СУБД, а не средство IPC;
  
• Использования Redis’a как хранилища истории защищает нас от SQL-инъекций в текстах сообщений;
  
• Проблема масштабируемости не стоит и в обозримой перспективе не встанет. Кроме того, эта самая масштабируемость в контексте данной задачи достигается скорее за счет увеличения API-лимитов, нежели горизонтального наращивания вычислительных мощностей;
  
• Celery пока что не дружит с asyncio, а программный костяк проекта составляет уже реализованная с основой на asyncio библиотека.

Предметная
Система оповещения (объемлющая) исполнена в виде множества микросервисов. Удобства ради, интерфейсы, методы инициализации слоев данных, текста ошибок, а также некоторые блоки повторяющейся логики были вынесены в библиотеку core, которая, в свою очередь, опирается на: gino (asyncio обертка SQLAlchemy), aioredis и aiohttp.
В коде можно увидеть разные сущности, например, User, Contact или Allegiance. Связи между ними представлены на диаграмме ниже, краткое описание — под спойлером.