RidgeA

https://eng.uber.com/mysql-migration/

1. Кешировать можно все, что позволяет кешировать бизнес-логика. Мизерный прирост в 10-ти местах может дать суммарно лучше прирост, т.к. эти мизерные запросы не будут лишний раз насиловать базу и база сможет быстрее обслуживать запросы.
2. Можно кешировать страницы и http запросы на уровне веб-сервера, до php запрос не должен дойти вообще - это может дать прирость общей производительности.
3. Если это что-то вроде блога, где посты меняются не так часто, а то и вообще не меняются, можно основные странички сгенерировать в уже готовый html и отдавать их как статику через web-сервер. Менять эти странички на серваке в случае какого-либо изменения.

1. Почему MySQL?, возможно MongoDB или Cassandra подойдут лучше.
2. Какого рода статистика нужна по этим данным?
3. ИМХО лучше не класть в базу по одной записи, а аккумулировать записи и писать в базу (вне зависимости от базы) пачками. Для аккумуляции подойдет какой-то брокер очередей (например RabbitMQ). К. т. очереди позволят сгладить пики нагрузки - в базу будет писаться более-менее равномерно, в пики - просто будет увеличиваться очередь.

в чем, собственно, сложность?

----запрос---> сервис валидации <---- запрос валидный ----> бэкэнд
        ^                            |
        |                  запрос не валидный
        |                            |
        ----- 400 -----------

есть такая штука как https://golang.org/pkg/plugin/
не знаю подойдет ли, но если подойдет - то разделить приложение на 2 части - одна - веб-сервер, вторая - вся логика, которая подключается как плагин. Вот его, насколько я понял, можно менять по-горячему

Если не подойдет, и вопрос сохранения соединений критичен, то все-равно разделить на две части, но они между собой должны общаться по какому-то IPC каналу (tcp/unix/whaterver). Это позволит вторую часть перезагружать не трогая первую.