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

Наименее затратный:
select * from news order by `date_pub` ASC, где date_pub собственно дата публикации новости.
(Если новости не публиковались задним числом - можно и по id сортировать)

А далее цикл в php вида

$last_printed_month = '';
foreach ($news_list as $item) {
  $curr_month = date('Y-m',$item->date_pub);
  if ($curr_month!=$last_printed_month) {
   echo ($last_printed_month = $curr_month);
  }
  echo $item->title;
}

В вашем тестовом примере ничего не написано про год, но мне кажется он нужен :)
Если хочется писать месяц именно русскими буквами - надо написать крошечную функцию которая сконвертирует порядковый номер месяца - в строку :)

1) Вопрос использовать ли вообще ООП или нет - он очень условен.
Без ООП не работает любой современный фреймворк.
Поскольку MVC таки использовать надо - соответственно ооп у вас будет автоматом)

2) По поводу Symfony - абсолютно без разницы на каком именно фреймворке Вы пишите свой код.
Symfony мне кажется более сложен для начинающего, попробуйте Yii2 или Laravel.
Опять же повторюсь, это не принципиально. Можно взять любой микрофреймворк - это будет даже полезней с точки зрения развития начинающего разработчика.

3) API это по сути обычный набор скриптов, отличающийся от обычных страниц тем, что в web страницах вы отдаете html - а в API вы отдаете JSON/XML/что_то_ещё (я лично советую использовать JSON по целому ряду причин, но вопрос в целом холиварен)
REST API (опять же дефакто массовый стандарт) - это договоренность о некоторых базовых принципах, по сути о форматах запроса, ответа, об отсутствии состояний (stateless)
Возвращаясь к пункту 2 - многие фреймворки дают автоматизацию в построении rest api, например вот свежая статья с примерами по Yii2 habrahabr.ru/post/240149

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

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

Прошу прощения если получилось сумбурно, писал одновременно с утренним кофе :)

Если у Вас база обновляется редко, целиком и уже есть инструменты для этого - то можно и файлик на сервер заливать.

Но классическое решение - сделать REST api, которое будет отдавать контент в мобильное приложение. Заодно в рамках api можно сделать версионность, и отдавать не все данные, а только то что изменилось.

Есть!
bit.ly/1yziIkJ

Поскольку в общем случае верстку и натягивание на cms делают разные люди - то верстальщик делает html макет в котором какие то тестовые данные забиты статикой, а тот кто натягивает уже нарезает это на кусочки, вставляет вывод из базы итд.

У меня ASUS RT-AC68U вроде бы умеет все что Вам нужно

Вопрос с кучей придуманных ограничений.
1. Почитайте про MVC. И код понятнее станет и читабельнее, и упоминаний страниц не будет.
2. Если Вы хотите без перезагрузок - вам нужно написать js код, который при изменении формы будет слать ajax запрос и соответственно рендерить его на страницу.
api.jquery.com/jquery.ajax в самом конце примеры

Внезапно wiki https://ru.wikipedia.org/wiki/%D0%9F%D0%BE%D0%BA%D...
Если пользователь просмотрел только одну страницу сайта, то счётчик Google Analytics посчитает такое посещение как «отказ». Для уменьшения значения показателя отказов в панели аналитики за счёт учёта таких посетителей существуют специальные коды скриптов.

1. Скрипт на крон - однозначно плохая идея. Более правильная история - постоянно работающий скрипт который из очереди получает очередную задачу. Отличный вариант для организации очереди rabbitmq

2. Слабая связанность компонент это хорошо. В вашем случае однозначно api (не очень правда понимаю метания от php к java но дело Ваше. пишите на том, что лучше знаете) + расширяемые апи для внешних интеграций + интерфейсы цепляемые к апи.

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

3. С точки зрения быстродействия - Вы достаточно быстро упретесь в базу. Соответственно надо сразу думать о шардировании данных, о том как система будет себя вести в случае выхода из строя одной из задействованных в транзакции нод итд.

4. Вам важна data consistency. Сразу думайте про железо. Любые сервера горят. Брендовые сервера горят точно так же как и не брендовые. С учетом п3 - я бы делал полностью независимые друг от друга ноды, с физическим дублированием внутри ноды, и привязывал каждый счет к одной ноде.

5 [философский] Поймите важный момент - без ОЧЕНЬ серьезных инвестиций в маркетинг, проекты не взлетают. Если бы эти инвестиции были - Вы бы тут не писали (не в обиду). Соответственно вероятность того что к Вам внезапно придет огромный поток транзакций - стремится к нулю. К тому моменту когда Вы раскрутитесь - Вы успеете 5 раз сменить архитектуру проекта. Нельзя иметь одну архитектуру у стартапа собранного одним человеком, и у проекта с высокими HL/HA.
Пишите на чем нравится, у Вас будет куча времени что бы переписать узкие места например на C.

6 [юридический] Вы в курсе что Вам нужна пачка лицензий на осуществление деятельности в качестве оператора электронных денег и денежных переводов без открытия банковского счёта? :)

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