Если API начинает тормозить, первое решение обычно очевидно — добавить Redis. Но иногда оказывается, что проблема гораздо проще. В одном из сервисов PostgreSQL начал упираться в повторяющиеся запросы. Одни и те же данные запрашивались тысячами клиентов. Практически каждый HTTP-запрос заканчивался одинаковым SQL-запросом. Любопытство победило — вместо готового решения был написан небольшой кэш прямо внутри сервиса. На это ушло примерно полчаса.Результат оказался неожиданным: некоторые эндпоинты ускорились почти в 7 раз. Вот, почему это произошло и как работает такая схема.
Рубрика «golang»
Я написал кэш для API на Go за 120 строк кода — и PostgreSQL перестал быть узким местом (ускорение в 7 раз)
2026-03-20 в 17:31, admin, рубрики: Go, golang, postgresq, postgresql, SQL оптимизация, кэширование, ускорение веб-сервисовДавайте добавим в Go условное выражение
2026-03-20 в 16:15, admin, рубрики: Go, golang, компилятор go, Компиляторы, расширение языка, тернарный оператор, условное выражение, языки программированияЕсли вы являетесь Go-разработчиком, то вне зависимости от того, из какого языка программирования пришли в Go, наверняка когда-то задавались вопросами «А есть ли тут тернарный оператор? Нет? А почему?»
Конечно, можно заглянуть в секцию FAQ документации Go и найти там ответ авторов. Но останавливаться на этом — удел слабых, так?) Иногда ведь так хочется удобно написать присвоение результата в зависимости от условия... Без заведения лишних временных переменных, и может быть даже в одну строчку...
Почему большинство AI-агентов плохо работают на Raspberry Pi (и как я попытался это исправить)
2026-03-19 в 11:16, admin, рубрики: golang, homelab, llm, local ai, open source, Raspberry PiПроблема: тяжёлые AI-агенты на маленьком железе
Последнее время я экспериментировал с AI-агентами на Raspberry Pi 5.
И довольно быстро столкнулся с проблемой: большинство существующих агентных фреймворков оказываются слишком тяжёлыми для небольшого железа.
Типичная архитектура таких решений включает:
-
Python-фреймворк
-
несколько фоновых сервисов
-
orchestration слой
-
иногда векторную базу
-
довольно сложную конфигурацию
На сервере это нормально работает. Но на Raspberry Pi всё начинает ощущаться иначе:
-
долгий старт
-
лишние зависимости
Цифровая капсула времени на чистом Go: почему для вечности не нужны базы данных и фреймворки
2026-03-10 в 20:45, admin, рубрики: backend, Go, golang, nosql, архитектура, капсула времени, минимализмА что, если современные технологии для большинства вещей избыточны? В проекте «ЭХО» я решил проверить это на практике, создав цифровую капсулу времени для потомков. Цель — позволить людям оставить память о себе (фото и мысли) в максимально простом и «вечном» формате.
Технически это эксперимент по созданию системы на 250 млн анкет без баз данных, фреймворков и лишних слоев — только чистый Go и минималистичный Linux. В этой статье я поделюсь опытом, как заставить обычный ПК работать с такой нагрузкой, используя лишь стандартную библиотеку и файловую систему.
Как дата саинтист имиджборду писал
2026-03-01 в 18:15, admin, рубрики: golang, markdown, postgresql, алгоритмы и структуры данных, имиджборда, оптими, пет-проект
Дисклеймер
Я два месяца платил 300к человеку, который тихо скармливал мои задачи в ChatGPT
2026-02-25 в 9:15, admin, рубрики: chatgpt, github copilot, golang, llm, teamlead, качество кода, найм разработчиков, собеседование it, управление командой, фейк-опытУ меня небольшая продуктовая команда, 12 человек, пилим B2B-логистику. Go, React, PostgreSQL, всё на кубере. Предметка скучная снаружи, но внутри — ад: у каждого перевозчика свой API, и каждый API как будто писали в пятницу вечером. У СДЭК поле tariff_code в одном эндпоинте строка, а в другом число, я до сих пор не понимаю почему, и никто там не понимает, я спрашивал.
Observability своими руками: затаскиваем Prometheus, Loki и Grafana в Go-стартап на бесплатный VPS
2026-02-18 в 5:15, admin, рубрики: dashboard, Go, golang, Grafana, loki, metrics, observability, prometheus, start-up, стартапЯ Go-разработчик из крупной Bigtech-компании и один из основателей ИИ-помощника по налаживанию отношений Ближе. По сути это телеграм-бот, который принимает вопрос от пользователя по long-polling модели, обогащает его промтом, идёт в LLM, получает ответ, отправляет обратно пользователю. Контекст диалога и пользователи хранятся в Postgres, всего один инстанс приложения на Go, также cron, который отправляет уведомления с просьбой оставить обратную связь о продукте. Docker Compose для запуска нескольких контейнеров.
Redis больше не нужен?! Реализуем реактивный кэш на чистом PostgreSQL и Go
2026-02-05 в 8:15, admin, рубрики: Go, golang, in-memory cache, postgresql, redis, sql, SSO, базы_данных, кеширование, микросервисыПривет! 👋
В современной разработке мы привыкли решать проблемы производительности стандартным набором инструментов. "База не тянет? Поставь Redis!" — это стало почти рефлексом. Но всегда ли оправдано тащить в инфраструктуру лишний сервис, настраивать сетевые хопы и следить за инвалидацией, если ваша задача — это всего лишь быстрый доступ к небольшому справочнику?
В нашем Open Source проекте BMSTU-ITSTECH/SSOЧитать полностью »
Массивы и слайсы в Golang
2026-01-29 в 9:15, admin, рубрики: backend, Go, golang, задачи, массивы, массивы и слайсы в go, слайсыДля начала хотелось бы сказать, что же такое массивы и слайсы.
Массивы
Массив в Go - это структура данных, которая представляет собой упорядоченную последовательность элементов одного типа фиксированной длины.
Давайте рассмотрим на примере:
package main
func main() {
/*
Массив создаётся в таком формате:
Имя := [количество элементов массива] тип данных {элементы массива, через запятую}
*/
arr := [3]int{0, 1, 2}
fmt.Println(arr[1])
}
На примере выше был создан массив с 3-мя элементами и типом данных int.
После создания массива мы не можем изменять его вместительность, однако можем менять сами элементы.
Как перестать писать WHERE tenant_id и отдать безопасность базе (PostgreSQL RLS в Go)?
2026-01-21 в 9:22, admin, рубрики: backend, Database Security, golang, multitenancy, postgresql, RLS, testcontainers, архитектураВ одном из прошлых проектов случился «кошмар техлида»: в суматохе хотфикса было забыто добавление фильтра WHERE tenant_id = ? в одну из ручек API. В итоге один клиент увидел отчеты другого. Все быстро откатили, но я навсегда запомнил то холодное чувство в животе.
Когда начали проектировать архитектуру следующего проекта, я понял, что полагаться на внимательность разработчиков на код-ревью - это тупик. Рано или поздно кто-то устанет, ошибется, и данные снова протекут.
Искал способ гарантировать изоляцию данных так, чтобы ее физически нельзя было забыть.
Почему стандартные решения не подошли?