kazmiruk

сервер приложений - gevent
для обмена сообщениям - gearman
Очень неплохо показала себя подобная связка.

Можете использовать fastcgi_finish_request, если на сервере у вас стоит php-fpm. Его суть в том, что скрипт висит еще некоторое время (пока не выполнятся все операции) после ответа клиенту. Но это неправильный путь. Вреное решение будет примерно такое: вы присылаете аякс, валидируете данные, добавляете в очередь сообщений (я люблю gearman, но вы можете использовать любую другую) запись, что надо отправить письмо. Как только в очередь добавляется запись обработчик хватает его и отправляет.

Посмотрите в сторону фильтра Калмана. Точность очень высокая, сложно реализации - невероятно высокая )) Данный алгоритм используется в умных автомобилях гугла для предсказания траектории движения окружающих объектов. На udacity даже был курс, где обучали примитивному использованию данного алгоритма (https://www.udacity.com/course/cs373, https://www.udacity.com/course/cs271).
Если хочется проще (хотя зависит от количества измерений\параметров), то можно использовать простой инерционный алгоритм (для фронта движения графика темпиратуры задается импульс инерции движения, который вычисляется на основе параметров других измерений (2 дня назад было +5, вчера +8, сегодня +10, значит завтра будет +11, так как скорость замедления роста темпиратуры - в 2 раза каждый день. Пример для 2х измерений: градусы и время. В реальности надо еще учитывать ветер, влажность и т.п., что значительно усложняет все)).
Ну и 3ий способ - нейронную сеть научить делать предсказание. По сути обученная нейронная сеть будет делать то же самое, что и алгоритм выше, только логика действий будет зашита в функциях активации и весах.

Вы изначально неверно поняли картинку, посмотрите внимательно какие технологии используются на фронтэнде (HTML, CSS, JS). Обычно делается так:
бекэнд - любой язык, REST
фронтэнд - nginx отдает index.html (условно говоря на любой запрос) + стили + js (много кода на js. Фактически вся логика сайта написана на js). JS код уже смотрит на текущий адрес страницы, производит роутинг, рендерит layout (пока ни одного запроса к бекэнду, кроме инициализирующего), затем по ссылке он понимает какие данные ему нужны от бекэнда (к примеру список задач на сегодня) и делает асинхронный запрос (из js'а. Это может быть несколько запросов к разным частям апи). Получив ответ на этот запрос (в виде json) js разбирает его и рендерит на шаблон (все это на js). Таким образом мы получаем: бекэнд не занимается рендерингом шаблонов, значительная часть логики отрисовки и роутинга находится на клиенте и он сам с ней разбирается, гибкость системы (бекэнд может использоваться для мобильных приложений, к примеру).
То, что описали Вы - трудно назвать правильной архитектурой. По сути Ваш "фронтэнд" - обычный прокси запросов, который все также генерит Html на сервере (тратит ресурсы сервера, а не клиента) + еще курлом гоняет бекэнд. Прироста производительности с такой архитектурой Вы не получите.

Стоит. Задача очень хорошо накладывается на модель асинхронных событий. Дергать сервер аяксом, чтобы проверить есть ли новые сообщения - не риал тайм, а если дергать часто (чтобы приблизиться к риал тайм), то создадите сами себе проблемы в виде ддоса запросами от клиентов.

Вообще Вы сами ответили на свой вопрос: используем кластер, мастер и несколько воркеров (обычно по количеству ядер). Данные, которые необходимы всем храним или на мастере, или в носкл, как указали выше. Воркеры спрашивают разрешение на обновление данных и если текущая запись сейчас заблокирована кем-то, то ожидают. Если не заблокирована, то блокируют и обновляют, а затем освобождают. По крайней мере сам делал именно так.

www.ozon.ru/context/detail/id/6573935 - крутая книжка по мускулю. Объясняется как и что ищется + много чего еще. По постгресу лучше официальной доки, к сожалению, ничего не нашел + существуют различные расширения о которых надо читать отдельно. По монге - хорошие бесплатные курсы у 10gen, которые объясняют как и что происходит внутри монги (https://education.mongodb.com/)

Хоть Вы и просили не давать такой ответ, но для синхронного программирования не стоит использовать технологию, главный принцип которой асинхронность, так как Вы научите студентов плохому и их будет ждать много боли после окончания учебы и выхода в жестокий мир (до сих пор вспоминаю некоторых своих преподавателей тихим матерным словом). Да и не вижу проблем в асинхронном подходе для обучения. По сути "классический подход"
также асинхронен, но достигается это набором тридов, которые выполняют несколько запросов одновременно.
По сути вопроса: можно сделать код на ноде полностью синхронным используя синхронизирующую либу (waitsync, например).

Ваш вопрос звучит примерно так: как ничего не делая начать зарабатывать миллионы?
З\п в 100-120 тысяч доступна в основном мидлам (редко)\сеньорам. Т.е. наша цель - стать миддлом. Но есть одно но: миддлом никогда и никто не возьмет человека без опыта работы в реальных проектах. Тут все и рушится.
Варианты: учить стек технологий, как только почувствовали в себе силы - увольняемся с работы менеджера и идем устраиваться программистом на джуниора (продолжая много учиться дома после работы). Через 6 месяцев старательной работы (очень старательной, а не просто на отвали) пытаемся устроиться на миддла (и все равно продолжаем учиться). Снова очень старательно работаем и через год пробуемся на сеньора. Данный вариант возможен, если Вы реально талантливый человек. Я никогда не видел сеньора с опытом работы в 1,5 года.
А вообще Ваш вопрос меня немного обижает даже. Вы считаете, что программисты сильно не напрягаясь зарабатывают гору денег и при этом не привязаны к офису? Так-то каждый из нас годами учился и продолжает учиться до сих пор, чтобы угнаться за очень динамичным миром ИТ.

@d00mko видимо не потрудился прочитать статью, прежде чем посоветовать ее Вам. В статье как раз пытаются избавиться от мифов вокруг ноды.
По сути вопроса - нода вполне подходит для проекта любого размера и сложности (как и пхп, раби, питон, ява и т.п.) Никогда в жизни не сталкивался с ситуацией, что язык становился узким местом в веб приложении. Если Вы с этим столкнетесь, то значит Ваша архитектура уже идеальна, у вас миллионы пользователей и у Вас миллиарды денег, чтобы взять и переписать все с нуля где-нибудь на побережье океана попивая мохито, принесенное личным барменом.
Ява - готовьтесь к тому, что Вам надо МНОГО оперативной памяти. Разработка будет вестись долго, но большинство глупых ошибок Вы избежите в силу особенностей языка.
ПХП - готовьтесь к тому, что в Вашем коде будут появляться какашки, так как из всех пхп кодеров лишь доли процента могут написать хороший код. Это действительно очень трудно, когда язык сам манит писать все больше и больше какашек ) Лишь просветленные могут удержаться )
Нода - Вас ждет мир непонятного асинхронного кода, но как только наступит просветление, то Вы будете писать намного более эффективные приложения, чем Ваши товарищи пхпщники ) Наилучшее применение - чаты, кометы и т.п. Но и в качестве веб-сервера чувствует себя замечательно.
Питон - можно использовать и асинхронный подход и синхронный. Памяти жрет намного меньше, чем Java (личный опыт. разница была почти в 7 раз). По скорости работы практически не уступает яве. По скорости разработки разрывает ее в клочья
Раби - ничего не могу сказать дельного, но синтаксис мне не нравится.
Эрланг - если Вы действительно суровы и Вам нужна максимальная производительность - это Ваш выбор. Столько боли и страдания Вам не доставит ни один язык. Вы можете часами сидеть и тупить над одной строчкой кода, но каждый раз после написания такой строчки Вы будете впадать в экстаз ) Да и пока вы часами тупили над одной строчкой в эрланге на другом языке вам бы пришлось написать 200 строчек. Хардкор вариант, есть много тестов, уроков и примеров, но сам бы я не рискнул начинать проект на нем, так как моих знаний не достаточно, а найти разработчика - нереально.
Вообще, не пишите серьезные проекты на том, что хотите изучить или то, что модно. Пишите на языке, который лучше всего знаете.

1. Лучше сокет, так как не надо будет впустую теребить сервер каждые 3 секунды. Но надо помнить про поддержку сокета браузерами
2. Номер заявки. Применял похожу схему - относительно медленно работает передача из пхп через сокет, особенно если много данных. Достать из мускуля по PK очень дешевая операция.

1. Вместо обычно джойна делаем немного необычный:
SELECT *
FROM comments as c
INNER JOIN (SELECT * FROM articles LIMIT 10) as a
ON a.id = c.aticle_id
2. Одним запросом никак.
3. Одним запросом никак.

2 и 3 делается обычным селектом статей с limit или без, а затем выборкой комментариев для каждой статьи с лимитом или без.

В AppStore — нет. В Google Play скорее всего тоже.

However, there are few important guidelines to keep in mind as you design your application:

You must deliver a digital good or service within your application. Do not use In-App Purchase to sell real-world goods and services.

You may not offer items that represent intermediary currency because it is important that users know the specific good or service they are buying.

Items you offer for purchase may not contain, or relate to, pornography, hate speech, defamation, or gambling (simulated gambling is acceptable).