Golang
// сервис используют внешний API для построения маршрутов, // в рамках тарифа у нас есть ограничение по RPS. // Нужно спроектировать ratelimiter. // 100 rps type RouteClient struct { limiter } func (rc *RouteClient) Get(req string) string { // todo return rc.get(req) }
Готов ли к переезду в Елабугу?
Что будет, если закрыть уже закрытый канал? Если писать в nil канал?
Расскажи про начало карьеры — чем занимался до августа 2020 года?
Что находится под капотом map в Go? Как она реализована?
Что нам нужно сделать, чтобы ты увидел высокую инженерную культуру?
Как реализован garbage collector в Go и какие компромиссы он делает между latency и throughput?
Всегда ли наличие индекса — это хорошо? Всегда ли вариант с включённым индексом будет лучше, чем без него?
В чём измеряется cost в EXPLAIN? Что такое cost?
Есть ли у тебя вопросы к нам?
Что такое каналы в Go? Какие бывают? Как устроены под капотом?
В чём отличие массива от Slice в Go?
Когда делал изменения в микросервисе, думал ли на что ещё это может влиять?
Абстрактный кейс: сервис падает (OOM kill), ты не видишь никаких ошибок, в поде видишь что последний статус — нехватка памяти. Какова последовательность действий для диагностики и стабилизации сервиса?
Использовал ли на практике контексты? Расскажи.
Есть следующая схема базы данных -- Таблица клиентов CREATE TABLE customers ( id BIGSERIAL PRIMARY KEY, name VARCHAR(255) NOT NULL, city VARCHAR(255) NOT NULL ); -- Таблица товаров CREATE TABLE products ( id BIGSERIAL PRIMARY KEY, name VARCHAR(255) NOT NULL, category VARCHAR(100) ); -- Таблица позиций заказа CREATE TABLE order_items ( order_id BIGINT NOT NULL, product_id BIGINT NOT NULL, qty DECIMAL(10, 3) NOT NULL CHECK (qty > 0), -- 10 цифр, 3 знака после запятой price NUMERIC(10, 2) NOT NULL CHECK (price >= 0), PRIMARY KEY (order_id, product_id) ); -- Таблица заказов CREATE TABLE orders ( id BIGSERIAL PRIMARY KEY, customer_id BIGINT, order_date TIMESTAMP WITH TIME ZONE NOT NULL DEFAULT CURRENT_TIMESTAMP, status VARCHAR(50) NOT NULL CHECK (status IN ('pending', 'paid', 'shipped', 'delivered', 'cancelled')) ); 1. Выведите ТОП 10 по сумме заказов пользователей совершивших более 2-х заказов за последние 30 дней 2. Выведите ТОП 3 категорий по выручке за последние 6 месяцев
Представьте задачу: пользователю нужно получать уведомление о важном событии. Расскажите, какие основные части работы вы видите, какие зависимости, риски и как поймёте, что решение подходит.
Есть ли опыт с CI/CD? Что делал?
Проектирование масштабируемого мессенджера с поддержкой 150 млн пользователей, 75 млн DAU, 225 млн MAU, 1.2M read / 300k write QPS, 5 млн одновременных пользователей, 60 PB новых данных в год, рост 30% в год, P99 <200 мс для чтения, <300 мс для записи, SLA 99.95%. КОНТЕКСТ Необходимо спроектировать распределённую систему мессенджера, аналогичную WhatsApp, которая поддерживает как 1:1, так и групповые чаты, обеспечивает доставку сообщений, отображение online-статусов пользователей и передачу мультимедийных файлов (фото, видео, аудио). Система должна обеспечивать высокую доступность и низкую задержку, выдерживать высокий параллелизм и масштабироваться на глобальном уровне. ФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ - Поддержка личных (1:1) и групповых чатов с возможностью добавления/удаления участников - Отправка и получение текстовых сообщений и мультимедийных файлов Нефункциональные требования: - Нет явной реализации механизма end-to-end шифрования на уровне сервисов или клиентов, кроме общей аннотации. - Отсутствует явное описание шардингов и репликации баз данных по chat_id или user_id для масштабируемости и отказоустойчивости. - Нет явного компонента или механизма для обработки офлайн-синхронизации сообщений и delivery receipts. - Не прослеживается, как реализуется балансировка нагрузки между базами данных и сервисами, особенно при пиковых нагрузках. **Узкие места, на которые стоит обратить внимание:** (Далее в диаграмме показана архитектура с Load Balancer, API Gateway, Message Queue, Service, Cache, Database, Object Storage и CDN)
Какова мотивация перехода? Почему решил выйти на рынок?