Pull to refresh

Comments 18

Автор уже работает в одном из. :) Захочет — скажет где.
До «тренировочного лагеря» я бы оценил success rate процентов в 80%, после него у меня было не так много секций, но все прошли очень удачно. Собеседовался в G и F. А сейчас я пойду погуглю эти новый буквы после FAANG.
я бы оценил success rate процентов в 80%

Это success rate для одного раунда интервью, или для набора 4-5 раундов на onsite?
Попрошу также поделиться с достопочтенной публикой — насколько давно Вы проходили интервью (точности в 1-2 месяца будет достаточно) и в какую страну или часть света (США/Европа/UK/восток Азии); интересует в связи с недавними мировыми событиями...


А сейчас я пойду погуглю эти новый буквы после FAANG

Facebook
Apple
Amazon
Netflix
Google
Microsoft
Uber
Lyft
LinkedIn
AirBnB
XYZ — и.т.д.

это конкретно для дизайна, все мои секции были до веселья с ковидом

Еще можно упомянуть Cracking the Coding Interview — там есть глава про системный дизайн, почти слово в слово ваша статья.

спасибо, действительно много общих моментов
А как бы вы спроектировали этот пункт?
Лента новостей (twitter, instagram, facebook)
Предположим что посты в ленте должны шафлиться по какому-то алгоритму.
1) Собираем в реалтайме? Если да, то что используем?
2) Делаем предагрегацию? Если да, то что используем?
3) Что то другое.
Спрашиваю потому что недавно была такая задача и хочется сравнить свое решение с чьим то еще, ну и понять в ту ли сторону вообще пошел.
В большой живой системе будет нечто среднее. Несколько наводящих вопросов:
1. Сколько времени юзеру придется ждать, если его лента будет строиться каждый раз в реальном времени? Сколько может жить закэшированная версия? Какие события приводят к обновлению ленты?
2. Сколько места нам потребуется, чтобы хранить заранее вычисленные ленты для всех пользователей? Нужно ли нам хранить всю ленту? Для каких пользователей ленту можно не хранить?
3. Что делать с юзерами, которые подписаны на 10^n других юзеров? Что делать с Ким Кардашьян?
Часть ответов на эти вопросы можно найти в видео про twitter.
Попробую ответить.
1. Если лента каждый раз будет строиться в реальном времени, при большом количестве подписок можно вообще не дождаться. Закешированная версия живет, положим, 2 недели, TTL = 14 дней. К обновлению ленты приводят события: подписка, отписка, создание поста теми на кого мы подписаны, удаление поста, удаление пользователя.
2. Представим что у нас распределенное дешевое хранилище и место не ограничено. Необязательно хранить всю ленту, можно хранить некоторую промежуточную структуру из которой можно быстро построить ленту. Можно не хранить ленту для пользователей, которые не заходили в систему 1 год.
3. Для популярных пользователей можно вынести обработку в отдельный воркер, чтобы не тормозить середнячков.
Тут еще подумал про вопрос: Сколько времени юзеру придется ждать, если его лента будет строиться каждый раз в реальном времени?
Думаю сильно зависит от структуры хранения, если в качестве бд что то «привычное» (sql, популярные nosql), то ожидание скорее всего будет долгим.
Если же в качестве хранилища у нас граф(какая-то графовая база, например, с ребрами по подпискам и от пользователей к постам), то какое-то ожидание вообще может исчезнуть.
UFO just landed and posted this here
Впечатление такое, что описанные вещи в реальном проекте таких масштабов должны решаться отдельными департаментами. Если Вы решаете все эти задачи, то респект, конечно, но это уже что-то за гранью)
Но архитектурные сессии продолжают проводить и такие вопросы продолжают задавать разработчикам сеньор+.
По мне, это нужно для того, чтобы понять пытливость мышления, способность переварить информацию на человеческом языке и перевести ее в черновик технической реализации системы. Деталями уже будет заниматься департамент.
Как один популярный блогер отвечает здесь youtu.be/4iMMQUBmVA4?t=117.
Проблемы, из которых состоят дизайн-секции, можно встретить в любом проекте, который не помещается на одной машине. Когда это уже существующая система в большой компании, там будут и специально обученные люди, и дизайн-ревью, и все такое, но когда дело происходит в стартапе из 0.5 человек, или просто в новом экспериментальном проекте, все не так радужно. Самое интересное происходит в тот момент, когда мечты сбываются, и приходит миллион юзеров. Если система была спроектирована хорошо, то в нее можно насыпать еще 10^n машин и она продолжит работать и радовать пользователей, а если нет, то окажется, что нужно «срочно переписывать мультиплеер» и на это нужен месяц и тд. Пользователи при этом не будут ждать, пока вы прочитаете нужные книжки и сделаете все как надо. Собственно умение проектировать системы, которые не разваливаются под нагрузкой, проверяется на дизайн секции :)
Sign up to leave a comment.

Articles