Идемпотентность — звучит сложно, говорят о ней редко, но это касается всех приложений, использующих API в своей работе.

Меня зовут Денис Исаев, и я руковожу одной из бэкенд групп в Яндекс.Такси. Сегодня я поделюсь с читателями Хабра описанием проблем, которые могут возникнуть, если не учитывать идемпотентность распределенных систем в своем проекте. Для этого я выбрал формат вымышленных историй о стажёре Васе, который только-только учится работать с API. Так будет нагляднее и полезнее. Поехали.

Электронная коммерция — одна из самых больших и быстро растущих областей, в связи с чем она привлекает внимание как исследователей информационной безопасности, так и злоумышленников. Поэтому хотелось бы разобраться в некоторых аспектах механизмов безопасности, применяемых при проведении онлайн-платежей.

Один из протоколов, используемых для увеличения безопасности онлайн-платежей — 3D Secure. Это протокол, который был разработан на основе XML в качестве дополнительного уровня безопасности платежей, проводящихся без физического участия карты (card not present payment). VISA создала первую версию этого протокола, но вскоре его начали использовать и другие компании (Master Card, JCB International, AmEx, Мир), впоследствии объединившиеся с VISA в содружество EMV. EMV занимается поддержкой и развитием протокола 3DS.

Январь этого года был для меня не только чередой праздников, но и поводом отметить год, как мы полностью переехали на новый платежный шлюз. Для нас, как для сервиса подписки на духи, это одна из ключевых систем и если с ней есть проблемы, то это касается всех в компании. Сам переезд можно сравнить с хорошей книгой: есть экспозиция  - проблемы с прошлым сервисом, завязка как мы делали выбор между своей разработкой и готовым сервисом, развитие действия - когда мы начали работать над архитектурой и делать первые коммиты, кульминация - момент первого запуска и первые проблемы с ним и развязка, когда мы закончили миграцию всех клиентов. Звучит интересно? Тогда добро пожаловать под кат.

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

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

Одно из направлений разработки в Dodo — интернет-платежи. Для компании это скорее утилити-функция, чем основной бизнес, но всё же нам приходится делать кучу всего, чтобы дать клиентам лучший UX и у нас накопился опыт, которым хочется поделиться.

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

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

Рано или поздно любой разработчик или администратор СУБД, имеющий дело с MySQL, сталкивается с проблемой блокировок. Всё дело в природе MySQL как системы с конкурентным доступом на чтение/запись. Я расскажу о видах блокировок в MySQL, их преимуществах и недостатках, о проблемах, которые они вызывают, а также дам полезные советы по обнаружению и способам борьбы с блокировками.

От переводчика: выражаю огромную искреннюю благодарность Дмитрию Малову @malovdmitrijза консультации по ходу этого перевода, помощь в подборе формулировок, пояснение рисунков и незаменимую человеческую поддержку.

tldr; в статье рассмотрены приёмы, позволяющие ускорить обучение больших языковых моделей (LLM) и нарастить в них логический вывод. Для этого нужно использовать большое контекстное окно, в котором умещается до 100K входных токенов. Вот эти приёмы: ALiBi с подмешиванием в вектор позиции слова в последовательности (positional embedding), разреженное внимание (Sparse Attention), мгновенное внимание (Flash Attention),  многозапросное внимание, условные вычисления и GPU A100 на 80 ГБ.  

В минувшем году все только и говорили об ИИ и о том, как он может всё за вас сделать.

Мне нравится, когда кто-то или что-то работает за меня. Поэтому решил: попрошу-ка ChatGPT написать за меня новогодний пост:

«Эй, ChatGPT. А ты можешь реализовать большую языковую модель на SQL?»
«Нет, SQL не подходит для реализации больших языковых моделей. Язык SQL предназначен для выполнения запросов к данным, хранящимся в РСУБД и для управления этими запросами. Для реализации большой языковой модели требуются сложные алгоритмы, обширные датасеты, а зачастую — и фреймворки для глубокого обучения. SQL всеми этими возможностями не обладает.»

Что ж, лишний раз убеждаешься, что, если хочешь что‑то сделать хорошо – сделай это сам.

Давайте же воодушевимся этим оптимистическим планом и реализуем большую языковую модель на языке SQL.

Привет, Хабр! Меня зовут Евгений Абрамкин, я руководитель поддержки третьего уровня в направлении омниканальных решений Лиги Цифровой Экономики. Моя команда — последняя «инстанция» во флоу по решению инцидентов. Мы пишем доработки и фиксы, чтобы победить проблему клиента, а также можем предоставить оптимальную конфигурацию для системы, которая передана на эксплуатацию или требует масштабирования. Это может быть кластер Elasticsearch, балансировщики nginx или что поинтереснее — распределенная NoSQL СУБД Apache Cassandra.

В материале я расскажу именно об Apache Cassandra: какие ошибки можно совершить при ее использовании, на что стоит обратить внимание и чем лучше не пренебрегать.

Колоночная база данных — это такой тип базы данных, в которой данные группируются (хранятся и извлекаются) не по строкам, а по столбцам.

В традиционной строчной базе данных данные хранятся и извлекаются по строкам, что означает, что все столбцы строки должны храниться вместе. Однако в колоночной базе данных, ориентированной на столбцы, каждый столбец таблицы хранится отдельно, что позволяет более эффективно хранить и извлекать данные.

Одни из самых популярных колоночных баз данных – Apache Cassandra и Apache HBase.

Недавно в команде произошел случай, который заставил обратить наше внимание на статью 2013 года. Материал не потерял актуальности, а перевода я не нашел, поэтому решил заполнить пробел. Но сначала немного предыстории.

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

Буквально через два уровня абстракций я оказался в коде, датированном 2016-2017 годами, то есть занялся software archeology. В какой-то момент меня возмутило, что вместо интерфейса репозитория в конструктор класса сервиса была передана реализация. Ещё одним уровнем абстракции ниже оказалось, что это всё-таки был интерфейс, но назывался он просто ContentRepository, а не ContentRepositoryInterface, как написал бы любой адепт ООП и принципов SOLID. Это уже не лезло ни в какие ворота, и я потребовал у архитектора оснований (кстати, рекомендую его статью о том, как мы вдвое ускорили построение лент подписок). Он в свою очередь невозмутимо показал пункт внутренних правил оформления кода, где была проставлена ссылка на статью 2013 года («А» — археология, как и было сказано).

Под катом — перевод этого материала.

В Одноклассниках запросы пользователей обслуживает более 200 видов уникальных типов сервисов. Многие из них совмещают в одном JVM-процессе бизнес-логику и распределенную отказоустойчивую базу данных Cassandra, превращая обычный микросервис в микросервис с состоянием. Это позволяет нам строить высоконагруженные сервисы, управляющие сотнями миллиардов записей с миллионами операций в секунду на них.

Какие преимущества появляются при совмещении бизнес-логики и БД? Какие нюансы надо учесть, прибегая к такому подходу? Что с надёжностью и доступностью сервисов? Расскажем подробно об этом всём.

Многие проекты на Django начинаются просто: есть база данных и к приложению, которое крутится на сервере, идут обращения. Например, так начиналась Dodo IS (информационная система компании Додо Пицца, где работал автор сегодняшней статьи). Но если использовать Django из коробки, можно натворить много бед и встретить пачку антипаттернов. Возможно, вы встречали такое на старых legacy-проектах.

Евгений Пешков развивает сообщество DDD-практиков, рассказывая, какие проблемы решает Domain-Driven Design (предметно-ориентированное проектирование) в современном мире. На конференции Russian Python Week 2020 он выступил с рассказом об этом. Кстати, 19 августа пройдет встреча DDDevotion-сообщества, присоединяйтесь, будем о чем поговорить.

В сегодняшней статье будет его рассказ про то, как устроен Domain-Driven Design и какие инструменты использует, чтобы наиболее точно описать требования бизнеса и сам бизнес.

За последние несколько лет в сфере архитектуры ПО произошли огромные изменения. Идея единственного монолитного приложения или даже нескольких крупных сервисов, разделяющих общий массив данных, практически стерта из умов и сердец инженеров-практиков во всем мире. Преобладающими инструментами в создании современных бизнес-ориентированных приложений стали автономные микросервисы, событийно-ориентированная архитектура и CQRS. Вдобавок быстрый рост количества подключаемых устройств (мобильных, IoT) многократно увеличивает объем событий, которые система должна оперативно обрабатывать.

В статье рассказываем, за счет чего Apache Kafka работает достаточно быстро для современных проектов.

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

Статья подготовлена на основе открытого занятия из видеокурса по Apache Kafka. Авторы — Анатолий Солдатов, Lead Engineer в Авито, и Александр Миронов, Infrastructure Engineer в Stripe. Базовые темы курса доступны на Youtube.

Вячеслав Москаленко (Ленвендо)