Если вы не понимаете бизнес своей компании, вы не сможете полностью реализовать свои технические навыки. Крутой технарь на позиции СТО, который знает нюансы TOGAF и отличия Raft от Paxos — это хорошо, но мало. Вы должны принимать решения не только исходя из технических деталей задачи, но и с учётом реалий бизнеса, его потребностей и направления развития.

Меня зовут Олег Федоткин, я СТО компании Циан. В этой статье расскажу, почему понимание бизнеса так важно для ИТ-менеджеров, тимлидов и архитекторов, и как оно влияет на принятие технических решений и развитие карьеры. Больше и чаще на подобные темы я пишу в свой ТГ-канал «Инженер и Менеджер».

Кому будет полезна статья:

Менеджерам в ИТ: тим-/юнит-лидам, руководителям направлений и СТО. Без понимания бизнеса у вас не получится построить карьеру — это аксиома.

Специалистам выше уровня senior: staff-/principal-инженерам и архитекторам для выработки полезных для компании технических решений.

В данной статье обсудим проблемы, возникающие при конкурентной работе с данными, а также инструменты для их решения – атомарные инструкции, явные и неявные блокировки и уровни изолированности транзакций, реализованные в OLTP СУБД PostgreSQL, MySQL, SQL Server, Oracle с примерами на Go. Поговорим о деталях их реализации в указанных СУБД. На примере PostgreSQL проведем benchmark-тестирование производительности уровней изоляции с использованием инструмента pgbench

Привет, Хабр! Меня зовут Алексей Топчий, я уже более 20 лет работаю в IT. Прошёл все уровни: бэкенд, фронтенд, фулстек со множеством языков и технологий. В СберТехе занимался Единой фронтальной системой, в Яндексе участвовал в стартапе, связанном с FMCG. Сейчас занимаюсь сервисом ценообразования в сети магазинов «Пятёрочка» (X5 Group). 

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

Привет, Хабр!

Меня зовут Тимур Маннапов, и я самый обычный senior-разработчик в Mindbox.

На примере нашего продукта я расскажу, почему при загрузке CPU наполовину или меньше скорость параллельных вставок на SQL-сервере упирается в «невидимый» предел, а потом и вовсе замедляется. На нашем железе предел был в районе ~120 тысяч строк в минуту в одну таблицу. Поделюсь, как его преодолеть, не потратив годы на разработку и миллионы на новый сервер.

Если у вас на машине стрелочка показывает, что у вас осталась половина бака, то у вас точно осталась половина бака? На самом деле больше, так как современные машины врут и топлива еще немного есть, даже когда стрелка на нуле - забота об альтернативно одаренных водителях. А если сервер показывает 50% cpu, то сколько ресурсов у нас осталось?

Для многих ответ ясен, и это не 50%. Поэтому извините, если многие вещи будут вам очевидны. А вот для менеджеров, например, которые планируют ресурсы, это может быть открытием.

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

…Если паттерны доступа существенно изменятся, то может потребоваться полная повторная обработка всех данных».

Всем привет, меня зовут Александр Матюшенко, я инженер по автотестированию в одной из платформенных команд в Альфа-Онлайн. В статье хочу рассказать, как внедрить функционал скриншот-тестирования в проект E2E автотестов с использованием библиотеки aShot от Yandex. Возможно, в этой статье я добавил излишне много кода на Java, но хочется более подробно показать, как это работает.

Привет! Меня зовут Дима, я архитектор в Купере. Сегодня расскажу о шаблоне проектирования Strangler, который мы использовали для поэтапного выноса бизнес-логики из монолитной системы в отдельный сервис. 

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

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

Сравнение хранилищ данных AoS и SoA

Сегодняшняя тема посвящена нелегким взаимоотношениям клиентского приложения и сервера PostgreSQL: как на ровном месте, неудачной архитектурой приложения, можно обеспечить себе хронические проблемы производительности.

Рассмотрим классические ситуации, когда разработчики начинают жаловаться на производительность БД - а виновата-то и не она!

1. Масштабируемость / Scalability

• Масштабируемость — это способность системы поддерживать возросшую нагрузку путем добавления дополнительных ресурсов
• Примером является добавление дополнительных серверов для обработки увеличившегося веб-траффика
• Что такое масштабируемость и как ее достичь?

2. Балансировка нагрузки / Load Balancing

• Балансировка нагрузки — это разделение входящего сетевого траффика между несколькими серверами для снижения нагрузки на каждый из них (во избежание того, чтобы на один сервер приходилось слишком много траффика)
• Примером является распределение веб-траффика между несколькими экземплярами EC2 с помощью сервиса AWS Elastic Load Balancer (ELB)
• Понимание балансировки нагрузки

Когда я писал свою статью про интерфейсы в JS на примере фильма "Перевозчик" с Джейсоном Стейтемом, я решил использовать ChatGPT, чтобы он мне помог с фактологией. Например, выяснить, сколько весила сумка с девушкой-китаянкой и откуда-куда её должен был перевезти Фрэнк Мартин (герой Стэйтема). Хотя я пересмотрел фильм перед написанием статьи, поиск нужных сцен казался мне утомительным, и я решил срезать путь, обратившись к ChatGPT. Ведь всем известно, что ИИ скоро выкинет старый добрый поиск через Гугл на обочину истории.

Однако, результат меня разочаровал. Если коротко, то ChatGPT (как и любая LLM) работает с вероятностями и ей очень сложно, на грани невозможного, признать, что она чего-то там не знает. Она будет выдавать всякий мусор с очень низким правдоподобием, но так не скажет "извини, чувак, я не в курсе". Ну а если с деталями, то добро пожаловать под кат.

О сложных системах простыми словами.

В шпаргалке на высоком уровне рассматриваются такие вещи, как протоколы коммуникации, DevOps, CI/CD, архитектурные паттерны, базы данных, кэширование, микросервисы (и монолиты), платежные системы, Git, облачные сервисы etc. Особую ценность представляют диаграммы — рекомендую уделить им пристальное внимание. Полагаю, шпаргалка будет интересна всем, кто хоть как-то связан с разработкой программного обеспечения и, прежде всего, веб-приложений. Буду признателен за помощь в уточнении/исправлении понятий, терминологии, логики/алгоритмов работы систем (в рамках того, что по этому поводу содержится в оригинале), а также в обнаружении очепяток.

Выражаю благодарность Анне Неустроевой за помощь в редактировании материала.

Возможно, немного другой формат шпаргалки покажется вам более удобным.

System Design (сборник на английском языке).

Привет! Меня зовут Вадим Клеба, я руковожу командой бэкенд-разработки в Телемосте. Последние девять лет я разрабатываю высоконагруженные распределённые системы. Раньше я разрабатывал search-as-a-service-решение с эффективным полнотекстовым поиском с учётом релевантности.

В статье расскажу, как в Яндекс 360 строили API в течение десяти лет без дропа обратной совместимости, выдерживающий сейчас сотни тысяч RPS. Вы узнаете, какие подходы мы изначально закладывали, чтобы наш API прожил так долго. 

«Баннерная крутилка» —  один из самых высоконагруженных сервисов в Яндексе. Он умеет переживать 700 тысяч RPS, а иногда и больше. Каждый раз, когда приходит запрос, крутилка должна просмотреть базу из миллиарда документов и выбрать из них самые релевантные для пользователя. При этом выдерживаются весьма жесткие временные рамки: 99% всех запросов обрабатываются менее чем за 200 миллисекунд.

Какими принципами стоит руководствоваться при построении подобных высоконагруженных систем? Как устроены стадии отбора документов? Какое участие в ранжировании принимает ML? Обо всём этом на недавнем мероприятии для разработчиков в Ереване рассказал Артём Ваншулин, руководитель разработки ранжирования в команде баннерной системы. Сегодня мы делимся с сообществом текстовой версией его доклада. Передаём ему слово.

Всем привет, меня зовут Артемий, я работаю старшим Android-разработчиком в команде пользовательского профиля в RuStore. Мой опыт в индустрии уже 8 лет. За это время я успел поработать в разных проектах и компаниях. У меня был опыт работы в проекте, в котором было свыше 300 модулей и больше 60 Android-разработчиков. Такие условия заставляют задуматься о масштабируемости на принципиально ином уровне.

Сегодня я расскажу о способах обеспечения масштабируемости проекта и как этому может навредить неправильное восприятие Чистой Архитектуры (далее — ЧА). Предупреждаю сразу, это лонгрид в двух частях!

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

Если не читали первую часть, настоятельно рекомендую это сделать, чтобы оставаться в контексте.

Итак, продолжим.

Всем привет! Меня зовут Бургомистренко Кристина и я — системный аналитик в компании заказной разработки Rubius. В этой статье я рассказываю про свой опыт проектирования и сравниваю несколько популярных инструментов для создания вайрфреймов, которые может использовать в своей работе бизнес/cистемный аналитик.

Для любого разработчика глубокое понимание основных принципов системного проектирования является необходимым условием для создания стабильных и масштабируемых программных систем, способных обеспечивать высокую производительность. Системное проектирование (System Design) включает разработку архитектуры и структуры программной системы, направленную на удовлетворение специфических требований и обеспечение требуемых показателей производительности.

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

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