D
Не, это просто шлюз для отправки данных
Кстати, а если кучей письма отправлять нельзя, то как быть? Ведь даже если асинхронно их дёргать, то лимит запросов в секунду всё равно ж есть какой-то
Size: a a a
2021 February 05
И
Кстати, а если кучей письма отправлять нельзя, то как быть? Ведь даже если асинхронно их дёргать, то лимит запросов в секунду всё равно ж есть какой-то
Есть, мне 14 писем поставили амазоновцы на проект
И
Говорят если нужно будет больше- напишешь
D
Есть, мне 14 писем поставили амазоновцы на проект
14 в секунду? Чего-то реально мало (нам бы не хватило точно)
D
Да, можно сделать очередь и из неё читать и отправлять, но тогда воркер придётся делать один (иначе RPS регулировать не получится)
D
Говорят если нужно будет больше- напишешь
А как на уровне кода контролируете RPS к их API?
И
А как на уровне кода контролируете RPS к их API?
Никак лол
D
Никак лол
Я вот тоже с такой фигнёй часто сталкиваюсь. Потому что получается либо немасштабируемо (если семафоры юзать), либо контролировать RPS не получится
AB
14 в секунду? Чего-то реально мало (нам бы не хватило точно)
Да им пишешь они без вопросов сразу повышают
D
Либо юзать Редис для лока, но это такое себе
D
Да им пишешь они без вопросов сразу повышают
Я не конкретно даже про SES, а вообще. Часто ж бывают задачи, когда надо насиловать чьё-то API
LK
Просто в микросервисной архитектуре не надо упарываться и дробить всё подряд. Вот есть у меня в конторе, скажем, 10 проектов, и все они имеют функцию отправки письма. Почему мы не вынести эту общую логику в отдельный проект, чтобы не дублировать? Микросервис это или сервис называется - значения не имеет
хотя бы потому что у тебя могут все 10 мс перестать отсылать email + бизнес логика может со временем отличаться
можно тогда получить blast radius нихеровый
ну и пример так себе, сейчас используют готовые сервисы для отправки
можно тогда получить blast radius нихеровый
ну и пример так себе, сейчас используют готовые сервисы для отправки
LK
А как на уровне кода контролируете RPS к их API?
error retries и exponential backoffs
LK
кстате, допустим сервис для отправки писем перестает работать
твои сервисы накапливают где-то там в очередях письма которые не вышло отправить в мс отправки писемь
при условии что вам нужно обязательно письмо отправить
потом когда сервис почты подымется, он получить дохерища запросов на отправки писем которые накопились и опять упадет
твои сервисы накапливают где-то там в очередях письма которые не вышло отправить в мс отправки писемь
при условии что вам нужно обязательно письмо отправить
потом когда сервис почты подымется, он получить дохерища запросов на отправки писем которые накопились и опять упадет
LK
ну типа не успеет заскейлится
LK
хотя бы потому что у тебя могут все 10 мс перестать отсылать email + бизнес логика может со временем отличаться
можно тогда получить blast radius нихеровый
ну и пример так себе, сейчас используют готовые сервисы для отправки
можно тогда получить blast radius нихеровый
ну и пример так себе, сейчас используют готовые сервисы для отправки
это про то что можно допустить ошибку в 1 сервисе и получить при этом проблемы в 11 сервисах
D
это про то что можно допустить ошибку в 1 сервисе и получить при этом проблемы в 11 сервисах
И что? Покрывай код тестами. Так можно и в биллинге основного проекта косякнуть и обанкротить фирму
D
Странный аргумент, если честно
LK
И что? Покрывай код тестами. Так можно и в биллинге основного проекта косякнуть и обанкротить фирму
господи, как вроде если ты напишешь тест то у тебя не будет ошибок в коде или тесте
D
господи, как вроде если ты напишешь тест то у тебя не будет ошибок в коде или тесте
Будут, но вероятность их уменьшается