Pull to refresh
0
Send message

они всё до сих пор используют строго вертикальную модель масштабирования? до сих пор если не попадают в кэш, то джойнят по 5-12 таблиц?

ктонибудь организовывал через токены доступ к видео? чтобы их с помощью софта не скачивали

Сидит на заборе, ждет пока ему на email всю информацию напишут, а тут нос поднял, всех обзывает "подобными", пишет так как будто с вершины горы с "превосходством" :DDDD
Хорошо что сейчас жалобы хабр быстро принимает и разбирает. Так же отправил вторую жалобу за рекламу сторонних ресурсов. Удачи вам.

добрый день.
"(я писал про это в Telegram-канале)."
Вы выкладываете дампы? или как всегда только болобольство без линков \ пруфов и т.д.?

одно дело заплатить трудом, поддержкой и.т.д. а другое кажется они переделали на непозволительные юзкейсы для фин проекта.
Смотрите мой второй пункт (пока они его не прокоментировали):
https://habr.com/ru/company/simbirsoft/blog/512310/#comment_21883146

в 2020 всё консольные команды руками пишут… дожили

добрый день. отличная статья. Смотрю в ыразбираетесь в алгоритмах.
Хотеел бы от вас статьи вроде, "найти тренд видео", "самые горячие за N часов" и.т.д.

у azure sb есть килерфича которую не встречал в других очередях. Это отказаться от сообщения на N минут, при этом очередь не блокируется, а вы пока обрабатываете следующие сообщения.

я извиняюсь, всё это поддерживает RDP RemoteFX?

зачем он нужен в век PWA?
делаешь 1 раз приложение на привычком веб стеке, сразу и для веба и для десктопа

был недавно бесплатный период, это был ужас .

Первые два больших комментария с 6 и с 3(мой) пунктами, если можно ответьте

после моего коммента выше, я думаю ты понял что для хайлоуда нотификации это сложно \ муторно, несколько вариантов, на целую статью тянет :D

смешной вы, посмотрим как вы там напишите типизированные пайплайны с атомарным выполнением с сложными nested array операциями.
Постгри это просто хайпажоры которые на коленки прилепили джэйсон, чтобы покричать "мы тоже так умеем".

А где же кафки, джойны стримов, отделение логики работы с файлами, подгрузка окон в чате, разделение систем сети и статистики, сложные фронтэнд джойны результатов от разных микросервисов, очереди на любые апдейт операции, ленивые высоконагруженые операции с враньем в ui как в инстграмме?

и опять пусто… ссылки на видео где? хотябы адреса форумов где размстили

"Как Django может обрабатывать 100 миллионов запросов в день"
Извиняюсь я из лагеря .net, а что джанго из коробки не может обработать такое ничтожное кол-во запросов? )

Вопросики:


1) Я один сломал мозг представив это? Кто, кого, когда обновляет… 3 абзаца абсолютно в разные направлениях. Просто прочитайте что вы написали:


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

API сервис счетов. Сервис сперва проверяет, есть ли актуальные данные пользователя в Cache. При успешном исходе возвращает данные, в ином случае отправляет запрос в Middle сервис счетов.

Например, сервис получает сообщение о входе пользователя в приложение и сразу же обновляет данные по счетам

2) По асинхронности, "сервис получает сообщение о входе пользователя в приложение и сразу же обновляет данные по счетам". Правильно я понимаю что всё асинхронно и допустим высокая нагрузка на систему, и я быстро зайду на страницу счетов, то могу увидеть старые данные? Считаете ли вы приемлемо такое в приложениях уровня финансы?


3) Вы используете кафку, так почему вы делаете столько промежуточных лишних звеньев(балансировщики, самодельные сервисы, кэши, сигналы для обновления кэшей), а не считаете в реалтайме в кафке?
Актуальный баланс можно сразу получать с помощью kafka\ktable в реальном времени. А изменения будут в виде отправить сообщений в топик balance {userId: 1, balance: +40},{userId: 1, balance: -40}

Information

Rating
Does not participate
Registered
Activity