Comments 18
А начало где?
Если не секрет — какой у Вас % success rate? В какие из Big N (FAANGUMULLAXYZ) уже отсобеседовались?
Автор уже работает в одном из. :) Захочет — скажет где.
До «тренировочного лагеря» я бы оценил 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 — там есть глава про системный дизайн, почти слово в слово ваша статья.
А как бы вы спроектировали этот пункт?
1) Собираем в реалтайме? Если да, то что используем?
2) Делаем предагрегацию? Если да, то что используем?
3) Что то другое.
Спрашиваю потому что недавно была такая задача и хочется сравнить свое решение с чьим то еще, ну и понять в ту ли сторону вообще пошел.
Лента новостей (twitter, instagram, facebook)Предположим что посты в ленте должны шафлиться по какому-то алгоритму.
1) Собираем в реалтайме? Если да, то что используем?
2) Делаем предагрегацию? Если да, то что используем?
3) Что то другое.
Спрашиваю потому что недавно была такая задача и хочется сравнить свое решение с чьим то еще, ну и понять в ту ли сторону вообще пошел.
В большой живой системе будет нечто среднее. Несколько наводящих вопросов:
1. Сколько времени юзеру придется ждать, если его лента будет строиться каждый раз в реальном времени? Сколько может жить закэшированная версия? Какие события приводят к обновлению ленты?
2. Сколько места нам потребуется, чтобы хранить заранее вычисленные ленты для всех пользователей? Нужно ли нам хранить всю ленту? Для каких пользователей ленту можно не хранить?
3. Что делать с юзерами, которые подписаны на 10^n других юзеров? Что делать с Ким Кардашьян?
Часть ответов на эти вопросы можно найти в видео про twitter.
1. Сколько времени юзеру придется ждать, если его лента будет строиться каждый раз в реальном времени? Сколько может жить закэшированная версия? Какие события приводят к обновлению ленты?
2. Сколько места нам потребуется, чтобы хранить заранее вычисленные ленты для всех пользователей? Нужно ли нам хранить всю ленту? Для каких пользователей ленту можно не хранить?
3. Что делать с юзерами, которые подписаны на 10^n других юзеров? Что делать с Ким Кардашьян?
Часть ответов на эти вопросы можно найти в видео про twitter.
Попробую ответить.
1. Если лента каждый раз будет строиться в реальном времени, при большом количестве подписок можно вообще не дождаться. Закешированная версия живет, положим, 2 недели, TTL = 14 дней. К обновлению ленты приводят события: подписка, отписка, создание поста теми на кого мы подписаны, удаление поста, удаление пользователя.
2. Представим что у нас распределенное дешевое хранилище и место не ограничено. Необязательно хранить всю ленту, можно хранить некоторую промежуточную структуру из которой можно быстро построить ленту. Можно не хранить ленту для пользователей, которые не заходили в систему 1 год.
3. Для популярных пользователей можно вынести обработку в отдельный воркер, чтобы не тормозить середнячков.
1. Если лента каждый раз будет строиться в реальном времени, при большом количестве подписок можно вообще не дождаться. Закешированная версия живет, положим, 2 недели, TTL = 14 дней. К обновлению ленты приводят события: подписка, отписка, создание поста теми на кого мы подписаны, удаление поста, удаление пользователя.
2. Представим что у нас распределенное дешевое хранилище и место не ограничено. Необязательно хранить всю ленту, можно хранить некоторую промежуточную структуру из которой можно быстро построить ленту. Можно не хранить ленту для пользователей, которые не заходили в систему 1 год.
3. Для популярных пользователей можно вынести обработку в отдельный воркер, чтобы не тормозить середнячков.
Тут еще подумал про вопрос: Сколько времени юзеру придется ждать, если его лента будет строиться каждый раз в реальном времени?
Думаю сильно зависит от структуры хранения, если в качестве бд что то «привычное» (sql, популярные nosql), то ожидание скорее всего будет долгим.
Если же в качестве хранилища у нас граф(какая-то графовая база, например, с ребрами по подпискам и от пользователей к постам), то какое-то ожидание вообще может исчезнуть.
Думаю сильно зависит от структуры хранения, если в качестве бд что то «привычное» (sql, популярные nosql), то ожидание скорее всего будет долгим.
Если же в качестве хранилища у нас граф(какая-то графовая база, например, с ребрами по подпискам и от пользователей к постам), то какое-то ожидание вообще может исчезнуть.
UFO just landed and posted this here
Впечатление такое, что описанные вещи в реальном проекте таких масштабов должны решаться отдельными департаментами. Если Вы решаете все эти задачи, то респект, конечно, но это уже что-то за гранью)
Но архитектурные сессии продолжают проводить и такие вопросы продолжают задавать разработчикам сеньор+.
По мне, это нужно для того, чтобы понять пытливость мышления, способность переварить информацию на человеческом языке и перевести ее в черновик технической реализации системы. Деталями уже будет заниматься департамент.
Как один популярный блогер отвечает здесь youtu.be/4iMMQUBmVA4?t=117.
По мне, это нужно для того, чтобы понять пытливость мышления, способность переварить информацию на человеческом языке и перевести ее в черновик технической реализации системы. Деталями уже будет заниматься департамент.
Как один популярный блогер отвечает здесь youtu.be/4iMMQUBmVA4?t=117.
Как один популярный блогер отвечает здесь youtu.be/4iMMQUBmVA4?t=117
Спасибо! До этого у него видел только https://www.youtube.com/watch?v=9mZmc6a0tmM
Проблемы, из которых состоят дизайн-секции, можно встретить в любом проекте, который не помещается на одной машине. Когда это уже существующая система в большой компании, там будут и специально обученные люди, и дизайн-ревью, и все такое, но когда дело происходит в стартапе из 0.5 человек, или просто в новом экспериментальном проекте, все не так радужно. Самое интересное происходит в тот момент, когда мечты сбываются, и приходит миллион юзеров. Если система была спроектирована хорошо, то в нее можно насыпать еще 10^n машин и она продолжит работать и радовать пользователей, а если нет, то окажется, что нужно «срочно переписывать мультиплеер» и на это нужен месяц и тд. Пользователи при этом не будут ждать, пока вы прочитаете нужные книжки и сделаете все как надо. Собственно умение проектировать системы, которые не разваливаются под нагрузкой, проверяется на дизайн секции :)
Sign up to leave a comment.
Как я научился проходить архитектурные секции