А какой протокол взаимодействия между клиентами и c*one? Кассандровский (с расширением для поддержки транзакций) или что-то совсем кастомное?

Можете привести пример конфигурации REPLICATION для keyspace'ов, для которых вы всегда используете QUORUM, и которые находятся в разных ДЦ?

в четырех московских дата-центрах, что позволяет обеспечивать сетевую задержку менее 1 мс между ними

Я правильно понял, что тут речь идет о задержке <1мс именно между ДЦ?

Теперь понятно. Спасибо.
Можете еще немного рассказать о том насколько вырос перфоманс (и в каких кейсах) по сравнению c использованием cassandra driver?

Какой consistency level вы используете для чтения/записи в кассандру?

Я правильно понял, что у клиентов (для запросов вне Tx) указан единственный contact point — локальный Fat Сlient и отключен discovery (через whitelist policy?)?

Можете озвучить критерии, по которым вы определяете ненастоящую мраморную говядину?

Под многопоточностью вы имеете в виду thread'ы? Если да, то в nginx'е воркеры это тоже не thread'ы, а процессы. Thread'ы внутри nginx'а, насколько я помню, используются только для доступа к файловой системе.

Не очень понятно как в этой схеме решается ожидание событий от бекэнда (php в данном случае)

А почему у вас входными нодами для запросов являются master-ноды, а не coordinating-ноды?

У гугла уже достаточно давно карта на клиент (как веб, так и мобильные приложения) отдается в векторном виде и там рендерится. Просто c сервера, в зависимости от масштаба, отдаются не все объекты, а так же используется разные степени загрубления геометрии. К слову, Яндекс.карты для андроида с версии 5.0.0 (вышла около месяца назад) тоже стали векторными.

Перестали работать ns-сервера, которым делегированы домены.

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

А неизвестно как мониторить. Есть твиттер reg.ru (https://twitter.com/regru/with_replies), но там полезной информации нет, все ответы в стиле "мы работаем над восстановлением, извините за неудобства".

А еще вы путаете аутентификацию с авторизацией.

в большинстве случаев там где есть генерация и тд — используется минимум всех возможностей субд

Это смотря что вкладывать в понятие «минимум всех возможностей субд». С таким же успехом можно заявить, что большинство проектов использующих только raw sql используют минимум возможностей субд. Непонятно как это относится к обсуждаемой теме.

У вас очень странные вопросы, из серии «какая по вашему связь между теплым и зеленым»

Ну собственно изначальный посыл, что если используется генерация ddl, то вам не нужна РСУБД как раз и есть про «теплое и зеленое».

И как же использование orm нотации автоматически делает ненужными возможносности классических РСУБД? Какая, по-вашему, связь между способом описания схемы данных и, например, необходимостью иметь транзакции?

Это как вы такой вывод сделали?
В чем, по-вашему, принципиальное различие между хранением схемы в виде sql ddl кода и orm нотации?

Я совершенно не понял что хотел сказать автор в этой статье. Посмотрел его код. Автор написал еще одну orm, назвал это не-orm, и объявил все остальные orm неправильными.

Создайте в хост-системе пользователя foo c uid'ом 42, внутри контейнера создайте пользователя bar с таким же uid'ом и запустите из под него какой-либо процесс, затем в хост системе посмотрите список процессов, вы удивитесь, но с точки зрения хост-системы процесс будет запущен под пользователем foo.