-Электронные чеки в json виде.
NoSQL, например Mongo. отличный выбор для документо-ориентированных данных.
-Склады и автомобильные дороги для логистической компании
не понял что должно быть в базе. если просто справочник с адресами, то вероятно NoSQL.
если же привязка к координатам, то я бы использовал SQL и тип данных geography
-Генеалогические деревья
графовая NoSQL.
-Кэш идентификаторов клиентов с ограниченным временем жизни для движка аутентификации
Memcached/Redis. не нужна структура, ttl, большая скорость.
-Отношения клиент-покупка для интернет-магазина
MongoDB
Данные записываются на все узлы с задержкой до часа (асинхронная запись)
CAP: AP
PACELC: PA/EL
При сетевых сбоях, система может разделиться на 2 раздельных кластера
CAP: AC
PACELC: PA/EC
Система может не прислать корректный ответ или сбросить соединение
CAP: CP
PACELC: PC/EC
не могут. они противоречат друг другу. хотя если рассматривать систему как некий комплекс бд, то вполне вероятно что будут использоваться оба подхода в решении общей задачи.
Pub/Sub подразумевает под собой наличие подписчика и издателя.
издатель формирует и публикует в системе сообщения с каким-то временем жизни.
подписчик забирает нужные сообщения себе по какому-то фильтру и обрабатывает.
к минусам можно отнести асинхронность поступления данных от издателя к подписчикам, т.к. у одного издателя может быть множество подписчиков, что приведёт к созданию очередей. (либо же у одного подписчика несколько источников-издателей, что так же приведёт к очередям)
дополнение:
Под данную задачу подходят key-value бд, например Redis.
в плюсах перед реляционными будет скорость доступа к данным, простое горизонтальное масштабирование.
к недостаткам я бы отнёс сохранность данных,т.к. данных хранятся в оперативной памяти. пусть даже Redis и умеет периодически записывать на диск.
так же в недостатки можно записать ограниченность операций с данными, из-за чего практически невозможно быстро анализировать информацию в ячейках и собирать статистику.