d'Ivan

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

В MySQL можно через REGEXP_SUBSTR.
Но вообще, такой формат хранения создаёт кучу проблем. Переделывайте на нормальную таблицу (id_строки, id_языка, строка).

Фишка из 2015 года от сотрудника Hashicorp. Нужно создавать ASG c lifecycle-ом на каждую LC и разруливать переключение трафика на балансировщике.
В Terraform можно делать вот так:

resource "aws_launch_configuration" "myapp" {
  name_prefix = "myapp_"
...
resource "aws_autoscaling_group" "myapp" {
  name = "myapp - ${aws_launch_configuration.myapp.name}"
  min_elb_capacity =  = "${var.myapp_asg_min_size}"
...
  lifecycle { create_before_destroy = true }

Пока количество инстансов в статусе InService не достигнет min_elb_capacity, они не будут прицеплены к балансировщику. Затем уже сам балансировщик по хелсчекам у себя должен поменять статус новым инстансам как InService и начнёт пускать на них трафик, в этот же момент TF начнёт удалять старую ASG.

Думаю можно оценивать сложность языка количеством использованных абстракций или толщиной мануала) Так среди естественных языков русский или японский принято считать сложными, а английский сравнительно простым. Что, впрочем, вовсе не свидетельствует об интеллектуальном превосходстве россиян над англосаксами.))

Есть одна библиотека. gui.cs

Использовать VPN для шифрования трафика.

Пример замыканий:

package main
 
import (
    "fmt"
    "math/rand"
    "time"
)
 
type kelvin float64
 
func measureTemperature(samples int, sensor func() kelvin) { // measureTemperature принимает функцию в качестве второго параметра
    for i := 0; i < samples; i++ {
        k := sensor()
        fmt.Printf("%v° K\n", k)
        time.Sleep(time.Second)
    }
}
 
func fakeSensor() kelvin {
    return kelvin(rand.Intn(151) + 150)
}
 
func main() {
    measureTemperature(3, fakeSensor) // Передает название функции другой функции
}

Источник

Ext4 конечно если нужна надёжность и скорость

Файловую систему выбирают не для того, чтобы круглосуточно читать большие файлы - с этим справляется любая современная система (ntfs, ext4, да даже ext3 норм).
zfs берут если нужны дополнительные фичи - снепшоты и онлайн расширение за счет других устройств, если не хочешь в LVM
А так - любые другие файловые системы накладывают свои дополнительные расходы на фичи, поэтому не всегда имеет смысл брать что-то модное, если не пользуешься функционалом.

Посмотрите на https://www.duplicati.com/, он умеет сохранять на диск\NAS

https://habr.com/ru/post/114082/

Вы небось делаете кeys word_123_*?
https://redis.io/commands/keys

Warning: consider KEYS as a command that should only be used in production environments with extreme care. It may ruin performance when it is executed against large databases. This command is intended for debugging and special operations, such as changing your keyspace layout.

Используйте SCAN

Очередь это буфер, куда задачи попадают с разной скоростью, а из него сливаются равномерно, по мере готовности «рабочих» их принять.

В вопросе описана так-себе реализация с поллингом очереди. Различие без-очереди и с-очередью — в направлении инициативы:

• без очередей «рабочий» опрашивает базу снова и снова: «есть чё?». Это как из браузера ajax'ом пинговать сервер раз в секунду в поиске сообщений. Работает, но такое себе..
  
• с очередью инициатор процесса – брокер. Это брокер передаёт очередную задачу на исполнение первому освободившемуся «рабочему».
  

В первую очередь брокеры нужны для балансировки нагрузки и увеличения надежности и скорости работы системы в целом.

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

В случае работы с сайтом у вас будет 1 воркер, который будет просто сканировать таблицы на поиск неуведомленных пользователей. Если у вас будет 2 воркера, надо делать систему блокировок и т.д. Т.е. мы упираемся в проблему масштабирования. Для решения задачи разной скорости уведомлений, вы построите систему приоритетов или будете делать разные таблицы с разными воркерами. Это все будет работать, но нагрузка на базу будет серьезной и она будет увеличиваться с ростом пользовательской базы. Опять вы упретесь в тормоза.
Опять же есть письма, которые должны быть доставлены немедленно, вроде подтверждений аккаунта, смены пароля и т.д. Еще одна таблица? Дополнительный приоритет? Может так произойти, что вы некоторые пользователи вообще никогда не получат писем и уведомлений. Прийдется придумывать способ контроля.
Я уж не говорю о куче кастомных воркеров под каждую ситуацию. И их будет с десяток, не меньше.

Очереди решают, т.к. можно сделать их несколько и на для каждой настроить определенное количество абсолютно одинаковых воркеров. Пример с поллингом отвратителен и сейчас никто так не делает, а с очередями делают так.
У вас может быть цепочка из нескольких воркеров, когда результат работы одного помещается в очередь.
Например, когда надо сначала достать данные из нескольких разных медленных систем, отрендерить в шаблон, а потом отправить письмо. Сборка, рендеринг и отправка - три разные компонента, последние два из которых, можно активно переиспользовать для других целей изменяя лишь конфигурацию времени исполнения.
При таком подходе проще развивать кодовую базу, исправлять ошибки, т.к. они изолированы в одном месте, а не разбросаны по всей системе. И да, косяк в "горячем" модуле вы заметите немедленно. А самое прикольное то, что ваш косяк, пользователи и не заметят, для них это будет выглядеть как простая задержка, а у вас будет время на то, чтобы исправить ошибку. Сообщения посидят в очереди и все.
Но это еще не все, ваши воркеры могут быть написаны на разных языках программирования. Например пользователь может загружать фото на сайт на PHP, объекты распознаваться на Python, видео рендериться на Rust, а отправка писем может быть на Go. И такой подход может подойти для сложных систем с распределенными командами и различным уровнем компетенция в применяемых технологиях. Специалистов превосходно владеющих всеми приведенными технологиями просто единицы, и поверьте, они решают задачи совершенно другого уровня.

Так вы книгу то сперва прочитайте и сразу все вопросы сами по себе отпадут