Skip to content

summary.fa.md

Latest commit

 

History

History
310 lines (222 loc) · 21.9 KB

summary.fa.md

File metadata and controls

310 lines (222 loc) · 21.9 KB

؜طراحی سیستم: TikTok | مصاحبه Mock با Google TPM

این سند خلاصه‌ی یک مصاحبه‌ی طراحی سیستم است. ؜برای لحن و جزئیات، دیدن ویدیوی کامل توصیه می‌شود.

AI-Powered buttons

Teach Me: 5 Years Old | Beginner | Intermediate | Advanced | (reset auto redirect)

Learn Differently: Analogy | Storytelling | Cheatsheet | Mindmap | Flashcards | Practical Projects | Code Examples | Common Mistakes

Check Understanding: Generate Quiz | Interview Me | Refactor Challenge | Assessment Rubric | Next Steps

؜خلاصه‌ی یک‌صفحه‌ای (۲–۳ دقیقه مطالعه)

  • ؜؜صورت مسأله (یک‌خطی):؜ بک‌اندِ یک اپ شبیه TikTok را طراحی کنید که در آن کاربران ویدیوهای کوتاه آپلود می‌کنند و یک فید شخصی‌سازی‌شده می‌بینند؛ قابلیت‌های follow / like / favorite و تعاملات پایه را پشتیبانی کند.
  • ؜؜دامنه‌ی اصلی:؜ سرویس‌های بک‌اند، storage، caching، ساخت فید، scalability. ؜ ؜خارج از دامنه:؜ جزئیات کلاینت موبایل؛ جزئیات کامل الگوریتم recommendation؛ tagging؛ مدل کامل auth.
  • ؜؜اولویت‌های نافی‌(Non-Functional):؜ دسترس‌پذیری خیلی بالا (~۹۹٫۹۹۹٪)، latency پایین برای لود فید، مقیاس جهانی، الگوی read-heavy، و offload تحویل ویدیو با CDN.
  • ؜؜قیود و اعداد کلیدی (از مصاحبه):؜
    • ؜ویدیوها تا حدود ۱ دقیقه؛ فرضِ ~۵MB/min فشرده‌سازی (H.264) (فرض مصاحبه). ؜ [نکته: برای delivery مدرن از HLS/DASH تطبیقی با bitrateهای مختلف استفاده کنید؛ H.264 بد نیست اما HEVC/AV1 را برحسب device/licensing بسنجید.]
    • ؜حدود ۱M کاربر فعال روزانه (DAU).
    • ؜؜مثال رفتار Creator: حدود ۲ آپلود در روز برای هر کاربر ⇒ حدود ۱۰MB در روز (فقط payload ویدیو) (فرض مصاحبه).

معماری سطح‌بالا (متنی)

  1. ؜API Gateway + Load Balancer جلوی microservices.
  2. ؜Upload Service: متادیتا را در RDBMS می‌نویسد؛ بایت‌های ویدیو در Object Storage (مثل S3).
    نکته: در DB فقط signed URL نگه دارید؛ blobها immutable باشند؛ lifecycle برای cold tierها تنظیم شود.
  3. ؜Feed Service: روی GET /feed لینک‌های ویدیوهای از پیش انتخاب‌شده را برمی‌گرداند.
  4. ؜Pre-cache Service: playlistهای per-user را از قبل در Cache (مثلاً Redis) می‌سازد.
  5. ؜Read Replicas برای بار خواندن؛ Primary برای نوشتن‌ها.
  6. ؜CDN جلوی Object Storage برای تحویل جهانی.
  7. ؜Sharding (اختیاری) برای مقیاس‌دادن به write (بر اساس region یا key/hash).
  • ؜؜؜Trade-offهای مهم:؜
    • ؜؜precompute فید vs. ؜ranking on-demand (latency در برابر freshness).
    • ؜سادگی RDBMS vs. ؜الگوی read در NoSQL.
    • ؜؜replication سراسری (consistency) vs. ؜autonomy منطقه‌ای (latency).
    • ؜هزینه egress در CDN vs. ؜hit به origin و UX.
  • ؜؜ریسک‌ها/نقاط شکست اصلی:؜
    • ؜«thundering herd» روی ویدیوهای داغ بدون CDN.
    • ؜؜staleness در cache / تاخیر در invalidation و اثر بر freshness فید.
    • ؜اشباع primary DB در اسپایک‌ها (uploads, likes, follows).
    • ؜حرکت بین‌منطقه‌ای داده و ملاحظات compliance.
  • ؜؜فلش‌کارت مرور ۵ دقیقه‌ای:؜
    • ؜؜Q: bytes ویدیو کجا ذخیره می‌شوند؟ A: در object storage؛ DB فقط متادیتا + URL.
    • ؜؜Q: فید را چطور سریع نگه داریم؟ A: پیش‌محاسبه‌ی N آیتم برای هر کاربر در Redis و رفرش پس‌زمینه.
    • ؜؜Q: جداسازی read/write؟ A: primary برای write؛ read replicas برای خواندن‌های سنگین.
    • ؜؜Q: مقابله با اسپایک جهانی؟ A: CDN جلوی blobها؛ LB برای APIها؛ autoscaling؛ precompute برای انتقال بار.
    • ؜؜Q: کی shard کنیم؟ A: وقتی write DB گلوگاه شد؛ shard بر اساس region یا key.
    • ؜؜Q: consistency لایک/کانترها؟ A: eventual؛ آپدیت‌های idempotent طراحی کنید.

Ask AI: خلاصه‌ی اجرایی

؜برچسب‌ها (برای فیلتر بعدی)

  • ؜؜حوزه/صنعت:؜ social-media, streaming
  • ؜؜الگوی محصول:؜ feed, recommendation, object-storage, cdn, caching, job-scheduler
  • ؜؜نگرانی‌های سیستمی:؜ high-availability, low-latency, eventual-consistency, geo-replication, hot-key, autoscaling
  • ؜؜تکنولوژی/Infra (ذکرشده):؜ microservices, rest, postgres, redis, s3, cdn, load-balancer
    [نکته: برای event streamهای خیلی بزرگ (likes, follows) از یک log مقاوم مثل Kafka/Pulsar برای decouple کردن writeها از materialized viewها استفاده کنید.]

Ask AI: برچسب‌های مصاحبه

؜درک مسأله

  • ؜؜پرامپت اصلی:؜ بک‌اند TikTok با تمرکز بر آپلود ویدیوهای کوتاه و یک فید اسکرول‌ شونده؛ شامل follow/unfollow، like/favorite و comment (در حد بالا). ؜تمرکز روی بک‌اند.
  • ؜؜؜Use Caseها:؜
    • ؜آپلود ویدیو کوتاه با caption اختیاری.
    • ؜دیدن فید (ابتدا: حساب‌هایی که follow شده‌اند؛ اختیاری: trending/recs).
    • ؜تعامل: follow/unfollow، like/favorite، comment (در حد کلی).
  • ؜؜خارج از دامنه:؜ UX عمیق کلاینت، سیستم tagging، جزئیات کامل الگوریتم recommendation.
  • ؜؜؜APIها (در حد high level):؜
    • ؜POST /videos (ارسال متادیتا + لینک blob).
    • ؜GET /feed?user_id=... (بازگرداندن N لینک ویدیو بعدی).
    • ؜POST /user-activity (like, follow, ...)، و GET /user-activity (خواندن likes/follows کاربر). ؜ [نکته: ترجیحاً resourceهای مجزا (POST /likes, POST /follows) برای شفافیت و observability.]

Ask AI: درک مسأله

؜نیازمندی‌ها و قیود

؜بر اساس ویدیو؜

  • ؜؜؜Functional:؜ آپلود ویدیو (+caption)، مشاهده‌ی فید تک‌ویدیویی (اسکرول)، follow creators، like/favorite، comment سبک.
  • ؜؜؜Non-Functional:؜ «highly available» (~۵ ناین به‌عنوان هدف)، latency پایین برای فید، مدیریت الگوی read-heavy، scale برای اسپایک‌ها.
  • ؜؜ورودی‌های capacity:؜ ~۱M DAU؛ ویدیوها تا ۱ دقیقه؛ فرض ~۵MB/min و ~۲ آپلود/نفر/روز؛ bytes ویدیو در blob store؛ تحویل با CDN.

؜فرضیات (توسط کاندید در ویدیو)؜

  • ؜۵MB/min برای H.264 و «۲ آپلود/روز/کاربر» فقط برای sizing تقریبی است. ؜ [نکته: در تولید واقعی با telemetry مشاهده‌شده و prefetch depth تأیید‌شده با A/B اندازه‌گیری کنید.]

Ask AI: نیازمندی‌ها و قیود

؜برآورد سرانگشتی

  • ؜با اعداد ویدیو:
    • ؜؜نوشتن ویدیو به‌ازای هر کاربر/روز:؜ حدود ۱۰MB (۲ × ۵MB). ؜
    • ؜؜اثردست متادیتا:؜ حدود ۱KB به‌ازای هر کاربر/روز (مرتبه‌ی حدودی). ؜
    • ؜؜نتیجه:؜ storage غالباً توسط blobها اشغال می‌شود؛ روی lifecycle + CDN تمرکز کنید. ؜
  • ؜؜Peak QPS/egress عددی‌سازی نشده است.

در صورت نیاز به دقت بیشتر: در ویدیو بیان نشده—از عدددهی صرف‌نظر می‌شود.

Ask AI: برآورد

؜معماری سطح‌بالا

  • ؜؜؜Ingress:؜ کلاینت → API Gateway/Load Balancer → سرویس‌ها. ؜ [نکته: ترجیح blue-green/rolling پشت LB؛ هر جا شد canary.]
  • ؜؜؜Upload Service:؜ دریافت ویدیو + caption؛ ذخیره‌ی متادیتا (user_id، video_id به‌صورت UUID، URL به blob، caption) در relational DB؛ آپلود blob در object storage.
  • ؜؜؜Feed Service:؜ GET /feed ده آیتم بعدی را برای کاربر برمی‌گرداند؛ از Redis list keyed by user می‌خواند.
  • ؜؜؜Pre-cache Service:؜ job پس‌زمینه/Batch که playlistهای per-user را در Redis می‌سازد (زمان‌بندی‌شده یا event-triggered).
  • ؜؜لایه داده:؜ primary relational DB (مثل Postgres) برای write؛ read replicas برای بار خواندن و builder. ؜ [نکته: اگر joinها زیاد شدند، read modelهای denormalized / materialized view برای کاهش fan-out.]
  • ؜؜؜CDN + Object Storage:؜ CDN جلوی blob storage برای محتوای داغ و مسیریابی جهانی. ؜
  • ؜؜؜Scale-Out:؜ autoscaling برای سرویس‌ها؛ وقتی write saturated شد، sharding (مثلاً region-shard). ؜ [نکته: shard keyهایی انتخاب کنید که creatorهای داغ را داغ‌تر نکنند؛ consistent hashing با قابلیت rebalance.]

Ask AI: معماری سطح‌بالا

؜عمیق‌شدن در زیرسامانه‌ها

؜۸.۱ Uploads

  • ؜؜نقش:؜ دریافت ویدیو+متن؛ ذخیره‌ی متادیتا؛ قراردادن bytes در blob store؛ برگرداندن موفقیت.
  • ؜؜مدل داده (relational):؜
    • ؜users(user_id UUID, ...)
    • ؜videos(video_id UUID, user_id FK, blob_url TEXT, caption TEXT, created_at TIMESTAMP, ...)
  • ؜؜؜Scaling:؜ APIهای stateless را افقی مقیاس دهید؛ write به origin برای object store؛ DB فقط متادیتا. ؜
  • ؜؜گلوگاه‌ها:؜ اسپایک write در DB؛ multipart uploadهای بزرگ. ؜
    • ؜؜کاهش:؜ presigned PUT مستقیم به object storage؛ سرویس فقط commit متادیتا. ؜ [نکته: روی policy presigned محدودیت content-type/size بگذارید؛ اسکن/Moderation async.]

Ask AI: زیرسامانه - ؜Uploads

؜۸.۲ Feed & Pre-cache

  • ؜؜نقش:؜ سرو فید سریع؛ نگه‌داشت صف از پیش محاسبه‌شده‌ی لینک‌های ویدیو برای هر کاربر.
  • ؜؜استراتژی cache:؜ Redis list/set با کلید feed:<user_id> و ~۱۰ آیتم از پیش لود؛ رفرش هنگام مصرف یا زمان‌بندی.
  • ؜؜؜Consistency:؜ eventual؛ کمی staleness برای UX قابل‌قبول است. ؜
  • ؜؜؜Hot Key/Bottleneck:؜ ویدیوهای بسیار محبوب؛ کاهش با CDN و انتقال کار recommendation از مسیر request. ؜ [نکته: اگر مصرف همزمان زیاد شد، از rebuild همزمان فهرست‌ها بپرهیزید—work queue و builderهای idempotent.]

Ask AI: زیرسامانه - ؜Feed

؜۸.۳ User Activity (Likes, Follows)

  • ؜؜نقش:؜ ثبت likes/favorites؛ follow/unfollow؛ فراهم‌کردن read API برای builder.
  • ؜؜مدل داده (relational):؜
    • ؜follows(follower_id, followee_id, created_at, PK(follower_id, followee_id))
    • ؜likes(user_id, video_id, created_at, PK(user_id, video_id))
  • ؜؜؜Scaling:؜ خواندن‌ها از replicas؛ نوشتن‌ها idempotent با upsert. ؜ [نکته: برای شمارنده‌های بزرگ، شمارش‌ها را async در materialized counterها نگه دارید تا hot row نشود.]

Ask AI: زیرسامانه - ؜User Activity

؜؜Trade-offها و گزینه‌های جایگزین

موضوع گزینه A گزینه B گرایش ویدیو دلیل (طبق ویدیو)
ساخت فید precompute در cache on-demand در هر request precompute کاهش latency و بار DB؛ مناسب read-heavy.
ذخیره متادیتا Relational DB NoSQL KV/Doc Relational روابط ساخت‌یافته (users↔videos, FK) و queryها.
تحویل CDN جلوی blobs فقط origin CDN offload پهنای‌باند؛ مدیریت محتوای داغ و کاربران جهانی.
مقیاس نوشتن single primary + replicas sharding منطقه‌ای/کلیدی شروع با primary؛ بعد sharding وقتی write bottleneck شد.
دسترس‌پذیری LB روی سرویس‌های stateless مونولیت منفرد LB استقرار بدون‌وقفه و مدیریت اسپایک.

Ask AI: Trade-offها

؜قابلیت اطمینان، دسترس‌پذیری و کارایی

  • ؜؜هدف Availability:؜ حدود ۹۹٫۹۹۹٪ (در حد آرمان). ؜ [نکته: بودجه خطا per-tier؛ multi-AZ + failover سریع تأثیرگذارتر از یک عدد کلی.]
  • ؜؜؜Latency:؜ فید را با prefetching حدود ۳–۱۰ آیتم و fetch پس‌زمینه سریع نگه دارید.
  • ؜؜؜Backpressure/Shedding:؜ ترجیح با سرو کردن فید کمی قدیمی‌تر بجای خطا؛ اندازه‌ی cache مناسب.
  • ؜؜؜DR/Regions:؜ geo-routing را در نظر بگیرید؛ تکرار blobs از طریق CDN + origin cross-region (اگر لازم شد).

Ask AI: قابلیت اطمینان و کارایی

؜امنیت و حریم خصوصی

در ویدیو به‌صراحت نیامده. ؜ [نکته: auth روی همه‌ی APIهای mutating؛ دسترسی object storage با signed URL کوتاه‌عمر؛ pipeline سخت‌گیرانه‌ی moderation.]

Ask AI: امنیت و حریم خصوصی

؜؜Observability

در ویدیو به‌صراحت نیامده. ؜ [نکته: p95/p99 برای /feed و موفقیت upload؛ نرخ hit در cache؛ offload CDN؛ hot keyهای برتر؛ خطاهای per-region.]

Ask AI: Observability

؜پرسش‌های Follow-up (از مصاحبه‌گر)

  • ؜؜cache چه اثری روی latency و freshness دارد؟
  • ؜اگر ترافیک ۱۰x شد، گلوگاه‌ها کجاست؟
  • ؜درباره‌ی regions و global routing/CDN چطور فکر می‌کنید؟

Ask AI: پرسش‌های Follow-up

؜پرسش‌های کاندید (مدل‌شده)

  • ؜چه بخشی از فید در ابتدا باید personalized باشد و چه بخشی صرفاً follower-based؟
  • ؜هدف freshness برای ظاهرشدن upload جدید نزد followers چقدر است؟
  • ؜قیود compliance که روی region sharding یا data residency اثر می‌گذارند کدام‌اند؟

Ask AI: پرسش‌های کاندید

؜نکات کلیدی

  • ؜؜bytes ویدیو را از متادیتا جدا کنید: ؜object storage؜ برای bytes و ؜relational DB؜ برای متادیتا. ؜
  • ؜؜؜CDN؜ برای محتوای داغ و کارایی جهانی حیاتی است. ؜
  • ؜فید را ؜از پیش محاسبه؜ کنید تا latency اسکرول پایین بماند و بار read کاهش یابد. ؜
  • ؜برای خواندن‌های سنگین از ؜read replica؜ و برای نوشتن‌های سنگین در زمان مناسب ؜shard؜ کنید. ؜
  • ؜برای سیگنال‌های اجتماعی ؜eventual consistency؜ قابل‌قبول است؛ writeهای idempotent و counterهای امن طراحی کنید. ؜
  • ؜؜؜zero-downtime deploy؜ با LB و سرویس‌های چندنمونه‌ای.

Ask AI: نکات کلیدی

؜واژه‌نامه

  • ؜؜؜Blob/Object Storage:؜ ذخیره‌ساز مقاوم برای فایل‌های باینری بزرگ؛ آدرس‌دهی با URL.
  • ؜؜؜CDN:؜ لایه‌ی cache و مسیریابی سراسری برای کاهش latency و بار origin.
  • ؜؜؜Read Replica:؜ کپی فقط‌خواندنی از primary DB برای مقیاس‌دادن خواندن‌ها.
  • ؜؜؜Pre-cache Service:؜ job پس‌زمینه برای آماده‌سازی فید per-user پیش از درخواست.

Ask AI: واژه‌نامه

؜برنامه‌ی مطالعه (اختیاری)

  • ؜تمرین الگوی ؜upload → blob → metadata؜. ؜
  • ؜تمرین trade-offهای ؜precompute vs on-demand؜ برای فید. ؜
  • ؜وایت‌بورد ؜rollout جهانی؜: CDN، region routing، replication. ؜ [نکته: در هر طراحی auth بعدی، ذخیره‌ی پسورد را با Argon2id/bcrypt و کالیبراسیون cost بررسی کنید.]

Ask AI: برنامه‌ی مطالعه

؜درباره‌ی خلاصه‌کننده

من ؜Ali Sol؜ هستم، یک PHP Developer.