// Написать имплементации кеша с ttl (time to live) для структуры User. // В качестве ключа можно использовать User.ID // мы хотим чтобы было потокобезопасно // мы не хотим получать записи с просроченным ttl при операции чтения // мы хотим чтобы записи с просроченным ttl удалялись и не хранились // API get/set/del
VK CloudРасскажи про использование событий (event-driven подход) на твоём примере
Холодильник.руНазови и раскрой две ключевые парадигмы программирования
Холодильник.руЧто такое таймауты и используешь ли ты их в работе?
AvitoЧто произойдёт при чтении из закрытого канала в Go?
Клиент может стримить голосовые напрямую из S3 через CDN, как и с картинками — загружать в ближайший по гео CDN?
Лига Цифровой ЭкономикиКакие виды веб-API вы знаете? Чем REST отличается от RPC по сути?
Как в Go обрабатываются ошибки? Чем отличаются errors.Is и errors.As?
YadroЧто нужно, чтобы запустить сервис в Kubernetes?
СБЕР/* Есть приложение с микросервисной архитектурой. Микросервис можно абстрагировать с помощью интерфейса Backend. Для доступа к одному экземпляру микросервиса можно использовать тип BackendImpl, который уже реализован. Для каждого микросервиса есть несколько десятков запущенных экземпляров, каждый из которых доступен по своему адресу addr. Однако отдельные экземпляры микросервиса ненадежны: они могут падать, быть недоступными либо перегруженными. Поэтому вам нужно реализовать тип Balancer, который также реализует интерфейс Backend и осуществляет client-side балансировку нагрузки между экземплярами микросервиса, выбирая каждый раз **наименее нагруженный** экземпляр. */
Весь опыт официально по ТК?
VKКакое оформление вас интересует — ИП, ГПХ или трудовая?
Какие индексы в PostgreSQL знаешь?
Пиковая нагрузка: 25k чтений / 5k записей в секунду Объем новых данных: 10 ТБ в год Пиковый параллелизм: 120k одновременных запросов Годовой рост пользователей: 30% Целевой p99 задержки: <150 мс для чтений, <400 мс для записей Целевая доступность: 99.95% Ваша задача — разработать архитектурное решение, которое позволит устранить текущие проблемы, обеспечит согласованность и отказоустойчивость, а также внедрить механизмы трассировки для полного мониторинга жизненного цикла заказа. Опишите механизм обработки сбоев, план миграции с текущей архитектуры, и объясните, как предложенное решение улучшит надёжность и прозрачность системы.
// Исправить код так, чтобы запросы были конкурентными и выводился код ответа // и в случае ошибки - выводили ее лог и продолжали обработку package main import "net/http" var addrs = []string{"[link] "[link] "[link] "[link] "[link] "[link] "[link] func main() { wg := sync.WaitGroup{} data := make(map[string]bool) for _, url := range addrs { wg.Add(1) if !data[url]{ data[url] = true go func(url string){ defer wg.Done() resp, err := http.Get(url) if err != nil { log.err return } log.info }(url) } } wg.Wait() }
Расскажи про модель GMP в Go. Как работают очереди, что такое handoff, work stealing, netpoller?
С чем связано решение уйти из Wildberries?
// Написать асинхронный обработчик задач как библиотеку // Клиент передаёт на вход некоторый объект (Task) с данными для выполнения задачи, // в нашем примере будем использовать пустую структуру. // Обработчик одновременно может обрабатывать не более N задач, // и не более X задач могут быть поставлены в очередь на обработку. // Если нет места в очереди, сразу возвращаем клиенту ошибку. // Задача берется в обработку если имеются на это свободные обработчики. // Иммитируем длительность обработки через time.Sleep(5*time.Second). // Как только очередная задача выполнилась - берём следующую задачу из очереди. // Если в очереди пусто, ожидаем новых задач от клиентов. // Со звездочкой: дополнить структуру Task и получать статусы задач через отдельный запрос
Если я сделаю 6 реплик сервиса при 3 партициях — это поможет ускорить чтение?
Почему умножение матриц задаётся именно таким правилом?