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

По-моему это борьба с ветряными мельницами. Сегодня один жалуется, завтра другой. Тут от самой сути сервиса проблемы будут.
А потом еще вдруг какой маски-шоу приедет в гости.

ORM изначально ЗАТОЧЕН на конкретный язык.
В каждом языке mapping объектов на СУБД реализуется несколько иначе.
Разве что вас заинтересуют близкие по идеологии ORM (когда один с другого слизан).

Ну так то куча инструментов, которые способны структуру данных прямо из SQL выдрать и перевести на ваш язык программирования. Что мешает использовать именно SQL в качестве "эталонного представления"?

у мускуля несколько кэшей. Кэшироваться может как план исполнения запроса, там и данные.
наиболее интересно данные - в 99% случаев наиболее значитмый эффект.

а у Вас, судя по описанию, либо запросы повторяются не слишком часто (и данные из кэше вытесняются), либо кэш небольшой (и он, опять-же, чистится)

попробуйте запустить mysqltuner и посмотрите на "Query cache prunes per day"

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

JsonRpc это всего лишь buzzword, обозначающий недоREST (ну или переREST) через http.
Устанавливаете superagent через npm и вперед:

request
  .get('https://api.mystend.domain.zone/jsonRpc')
  .send({ query: 'dogById', id: '13' }) /* тут вот некий объект, описывающий запрос согласно спецификации, которую вам должны предоставить разработчики вашего "JsonRpc" */ 
  .set('X-API-Key', 'foobar') // Ну и заголовочки (авторизация там может или еще что)
  .set('Accept', 'application/json')
  .end(function(err, res) { // Тут ответ этого самого JsonRpc
    expect(res.dogName).toEqual('Brownie');
  });

Хорошо знать фреймворк - это понятие довольно субъективное, и каждый человек может в него вкладывать свой смысл. Если Вы планируете искать работу с акцентом на изучаемые фреймворки думаю Вам будет достаточно:
1. Знание общих принципов работы фреймворка (что как устроено внутри), но тут нужно понимать что не стоит изучать каждый класс от корки до корки, т.к. это бессмысленная работа, фреймворки постоянно развиваются и модифицируются. Например, Вы должны знать что такое DI, как оно организовано в фреймворке, и как с ним работать. Но не нужно прям досконально знать код.
2. Чтение документации это хорошо, но практика всегда нужна. Вы не просто должны знать фреймворк по документации, Вы должны иметь опыт работы с ним. Как вариант можете придумать для себя какой-нибудь тестовый проект и реализовать его.
3. Паттерны, архитектурные принципы и т.п. тоже важны, если Вы их знаете - тогда это плюс.
4. СУБД. Для большинства проектов базы используются, поэтому помимо фремворка Вы должны так же хорошо ориентироваться в них, уметь писать сложные запросы, проектировать их и т.п.