DDIA·مطالعهSTUDY

نقشه راهRoadmap/ فصل ۱Chapter 1

انتخاب‌ها و هزینه‌های معماری سیستم‌های دادهTrade-offs in data systems architecture

معماریِ داده یعنی انتخاب بر اساس نیاز: چه چیزی را سریع‌تر کنیم و در برابرش چه هزینه‌ای بپذیریم؟ در این فصل تفاوتِ ثبتِ کار روزمره و تحلیل، دادهٔ مرجع و نسخهٔ مشتق‌شده، و اجرای تک‌ماشین و توزیع‌شده را دنبال می‌کنیم. A focused distillation for learning and interviews — eight interactive diagrams, comparison tables and a question pack.

۸8 نمودار تعاملیinteractive diagrams· محور: تریدآف، نه راه‌حل مطلقTheme: trade-offs, not silver bullets· زمان مطالعه: حدود ۴۵ دقیقهReading time: ~45 min

۰0 نقشه راه فصل و اصطلاحاتChapter map and terminology

ایده کلیدی فصلChapter thesis

معماریِ داده یعنی انتخاب بر اساس نیاز: چه چیزی را سریع‌تر کنیم و در برابرش چه هزینه‌ای بپذیریم؟ در این فصل تفاوتِ ثبتِ کار روزمره و تحلیل، دادهٔ مرجع و نسخهٔ مشتق‌شده، و اجرای تک‌ماشین و توزیع‌شده را دنبال می‌کنیم.

مثال فنی: مسیر یک سفارش در سه مخزن

وضعیت اولیه: سفارش id=42 با مبلغ 500 در PostgreSQL ثبت شده است.

اجرای مرحله‌به‌مرحله: رویداد تغییر، نسخهٔ نمایش را در Redis و سند جست‌وجو را در ایندکس به‌روز می‌کند. گزارش شبانه مبلغ را جمع می‌زند.

نتیجه و دلیل: خرابی Redis سفارش را حذف نمی‌کند؛ کش از مرجع بازسازی می‌شود. تأخیر انتقال می‌تواند نمایش را موقتاً قدیمی کند.

مثال‌های این فصل سناریوهای آموزشیِ برگرفته از کارهای روزمره‌اند. عددهای انتخاب‌شده برای توضیح‌اند؛ معماریِ داخلیِ یک شرکت مشخص را توصیف نمی‌کنند.

“There are no solutions, only trade-offs.” A data engineer’s job is not to memorize the best tool; it is to ask the right question: what access pattern is this system built for, and what does that choice cost?

سیستم data-intensive چیست؟What is a data-intensive system?

سیستم داده‌محور یعنی برنامه‌ای که سختی اصلی آن نگهداری، پیدا کردن و به‌روز نگه‌داشتن داده‌هاست. در سیستم محاسبه‌محور، سختی اصلی خودِ محاسبه است.

مثال فنی: دادهٔ بیشتر یا محاسبهٔ بیشتر؟

وضعیت اولیه: سرویس سفارش روزانه یک میلیون رکورد با customer_id و status نگه می‌دارد.

اجرای مرحله‌به‌مرحله: پرس‌وجوی وضعیت باید رکورد درست را با ایندکس پیدا کند؛ سرویس تبدیل ویدیو روی یک فایل، کدک را با CPU اجرا می‌کند.

نتیجه و دلیل: اولی بیشتر با نگهداری و بازیابی داده درگیر است؛ دومی بیشتر با هزینهٔ محاسبه. یک محصول می‌تواند هر دو نوع بار را داشته باشد.

If managing data is one of the main challenges of building the application, your system is data-intensive. In contrast, compute-intensive means the challenge is parallelizing one giant computation. Data-intensive concerns: storing and processing high volumes, managing data change, coping with failure and concurrency, and high availability.

بلوک‌های ساختمانی (که بارها در کتاب تکرار می‌شوند)Building blocks (recurring throughout the book)

هر ابزارِ داده بخشی از کار را انجام می‌دهد: پایگاه داده اطلاعات را نگه می‌دارد، کش خواندن را سریع می‌کند و پردازشگرها داده را به نتیجهٔ قابل‌استفاده تبدیل می‌کنند.

مثال فنی: پایگاه داده، کش و ایندکس چه می‌کنند؟

وضعیت اولیه: قیمت کالای P7 در مرجع 120 است؛ در کش هنوز 100 مانده است.

اجرای مرحله‌به‌مرحله: API خرید قیمت معتبر را از مسیر مرجع می‌گیرد؛ مصرف‌کنندهٔ تغییر، کش و ایندکس جست‌وجو را به نسخهٔ 120 می‌رساند.

نتیجه و دلیل: کش برای سرعت و ایندکس برای جست‌وجوست؛ هیچ‌کدام بدون قرارداد مشخص، مرجع تأیید قیمت خرید نیستند.

  • پایگاه داده‌ها: ذخیره داده برای بازیابی بعدی
  • کش: نگه‌داشتن نتیجه عملیات گران برای سرعت‌بخشیدن به خواندن
  • ایندکس جست‌وجو: جست‌وجوی کلیدواژه‌ای و فیلترهای پیچیده
  • پردازش جریانی (Stream Processing): واکنش فوری به رویدادها و تغییرات
  • پردازش دسته‌ای (Batch Processing): پردازش حجم زیادی از داده‌های جمع‌شده
  • Databases: storing data for later retrieval
  • Caches: memoizing expensive operations to speed up reads
  • Search indexes: keyword search and complex filters
  • Stream processing: reacting to events and changes immediately
  • Batch processing: crunching large accumulated volumes of data

اصطلاحات ضروریEssential terminology

فرانت‌اند بخش قابل‌دیدن برنامه است؛ بک‌اند درخواست را بررسی و اجرا می‌کند. اطلاعاتی که باید پس از پایان درخواست باقی بمانند، در یک محل ذخیره‌سازی پایدار نگه داشته می‌شوند.

مثال فنی: از مرورگر تا دیسک

وضعیت اولیه: کاربر دکمهٔ خرید را می‌زند و مرورگر POST /orders با request_id=r7 می‌فرستد.

اجرای مرحله‌به‌مرحله: بک‌اند اعتبار درخواست را بررسی می‌کند؛ پایگاه داده سفارش را ثبت می‌کند؛ پاسخ شامل order_id=42 برمی‌گردد.

نتیجه و دلیل: مرورگر کلاینت است، بک‌اند منطق برنامه را اجرا می‌کند و پایگاه داده مسئول نگهداری رکورد است؛ این سه الزاماً سه ماشین نیستند.

  • Frontend: کد سمت کلاینت (مرورگر/موبایل) — فقط داده یک کاربر را مدیریت می‌کند.
  • Backend: کد سمت سرور — داده همه کاربران را مدیریت می‌کند؛ اینجاست که چالش زیرساخت داده شکل می‌گیرد.
  • Data infrastructure: مجموعه پایگاه داده‌ها، کش‌ها و صف‌های پیام که کد برنامه با آن‌ها کار می‌کند.
  • کد برنامه معمولاً stateless است؛ هرچه باید بین درخواست‌ها بماند، باید در سمت کلاینت یا زیرساخت داده ذخیره شود.
  • Transaction در این فصل با معنایی کلی‌تر یعنی «خواندن‌ها و نوشتن‌های کم‌تأخیر که یک واحد منطقی‌اند» (تعریف دقیق در فصل ۸).
  • Frontend: client-side code (browser/mobile) — manages only one user’s data.
  • Backend: server-side code — manages all users’ data; this is where the data-infrastructure challenge lives.
  • Data infrastructure: the databases, caches and message queues the application code works with.
  • Application code is usually stateless; anything that must survive between requests lives on the client or in data infrastructure.
  • Transaction is used loosely in this chapter to mean “low-latency reads and writes forming one logical unit” (precise definition in Chapter 8).

۱1 سیستم‌های عملیاتی در برابر تحلیلیOperational vs analytical systems

ایده کلیدیKey idea

دادهٔ عملیاتی برای انجام کارِ همین حالای کاربر است؛ دادهٔ تحلیلی برای فهمیدن الگوهای تعداد زیادی از همین کارهاست. این دو نوع استفاده، نیازهای متفاوتی دارند.

مثال فنی: ثبت خرید در برابر گزارش فروش

وضعیت اولیه: ثبت سفارش فقط ردیف سفارش 42 و موجودی کالای P7 را تغییر می‌دهد.

اجرای مرحله‌به‌مرحله: گزارش ماهانه SUM(amount) GROUP BY city باید میلیون‌ها ردیف را بخواند. اجرای هم‌زمان هر دو روی منابع محدود صف ایجاد می‌کند.

نتیجه و دلیل: نسخهٔ تحلیلی رقابت منابع را کم می‌کند، ولی گزارش به‌اندازهٔ تأخیر انتقال از مرجع عقب می‌ماند.

Data in organizations lives two different “lives”: where it is created (operational services for end users) and where it is analyzed (a read-only copy for analysts and data scientists). Don’t mix the two.

چه کسانی با داده کار می‌کنند؟Who works with data?

همه با یک داده کار می‌کنند، اما سؤالشان یکی نیست: توسعه‌دهنده عملیات را می‌سازد، تحلیلگر گزارش می‌خواهد و مهندس داده مسیرِ رسیدن اطلاعات به گزارش را آماده می‌کند.

مثال فنی: مسئولیت‌ها روی یک خطای مبلغ

وضعیت اولیه: سرویس سفارش مبلغ را به ریال ثبت می‌کند، اما منبع دیگری تومان می‌فرستد.

اجرای مرحله‌به‌مرحله: توسعه‌دهنده واحد API را مشخص می‌کند؛ مهندس داده در تبدیل، واحدها را یکسان می‌کند؛ تحلیلگر جمع فروش را با نمونهٔ سفارش‌ها تطبیق می‌دهد.

نتیجه و دلیل: عدد نهایی صرفاً با افزودن سرور درست نمی‌شود؛ قرارداد واحد و کنترل کیفیت در زنجیره لازم است.

  • Backend Engineer: سرویس‌های خواندن/نوشتن برای کاربران (عملیاتی)
  • Business Analyst: گزارش برای تصمیم‌گیری مدیریت — Business Intelligence (BI)
  • Data Scientist: کشف بینش، مدل ML، قابلیت‌های داده‌محور محصول (پیشنهاددهنده، امتیاز ریسک، فیلتر اسپم)
  • Data Engineer: پل بین دو دنیا و مسئول زیرساخت داده
  • Analytics Engineer: داده را برای تحلیلگران مدل و تبدیل می‌کند
  • Backend engineer: read/write services for users (operational)
  • Business analyst: reports for management decisions — Business Intelligence (BI)
  • Data scientist: insight discovery, ML models, data-driven product features (recommenders, risk scores, spam filters)
  • Data engineer: the bridge between both worlds, owner of data infrastructure
  • Analytics engineer: models and transforms data for analysts

OLTP در برابر OLAPOLTP vs OLAP

در OLTP معمولاً چند رکورد مشخص را می‌خوانیم یا تغییر می‌دهیم. در OLAP تعداد زیادی رکورد را کنار هم بررسی می‌کنیم تا به آمار و الگو برسیم.

مثال فنی: دو پرس‌وجو، دو الگوی دسترسی

وضعیت اولیه: جدول orders صد میلیون ردیف دارد و روی id ایندکس شده است.

اجرای مرحله‌به‌مرحله: WHERE id=42 با ایندکس چند صفحه را می‌خواند؛ SUM(amount) برای کل سال حجم زیادی از ستون مبلغ را اسکن می‌کند.

نتیجه و دلیل: اولی نمونهٔ OLTP و دومی OLAP است؛ ایندکس مناسب اولی لزوماً گزارش دوم را سریع نمی‌کند.

Online Transaction Processing (OLTP): look up a few records by key (point query), then insert/update/delete per user input. Online Analytical Processing (OLAP): scan a huge number of records and compute aggregates (count / sum / avg) — not return individual rows.

ویژگیعملیاتی (OLTP)تحلیلی (OLAP)
الگوی خواندنpoint query — یافتن رکورد با کلیداسکن و تجمیع روی انبوه رکورد
الگوی نوشتندرج/به‌روزرسانی/حذف تک‌رکوردورود دسته‌ای (ETL) یا جریان رویداد
کاربر انسانیکاربر نهایی وب/موبایلتحلیلگر داخلی برای تصمیم‌گیری
نوع کوئریثابت و از پیش تعریف‌شده در کد برنامهدل‌خواه، اکتشافی (ad-hoc)
حجم کوئریتعداد زیاد، هرکدام کوچکتعداد کم، هرکدام پیچیده و سنگین
معنای دادهآخرین وضعیت فعلی دادهتاریخچه رویدادهای رخداده در طول زمان
اندازه دادهگیگابایت تا ترابایتترابایت تا پتابایت
مثالبررسی مجاز بودن یک عملیاتتشخیص الگوی تقلب/سوءاستفاده
PropertyOperational (OLTP)Analytical (OLAP)
Read patternpoint query — record lookup by keyScan and aggregate over masses of records
Write patternSingle-record insert/update/deleteBulk ingest (ETL) or event stream
Human userEnd user of web/mobileInternal analyst deciding things
Query typeFixed, predefined in application codeAd-hoc, exploratory
Query volumeMany, each smallFew, each complex and heavy
Data meaningLatest current stateHistory of events over time
Data sizeGigabytes to terabytesTerabytes to petabytes
ExampleChecking whether an operation is allowedDetecting fraud/abuse patterns
نکته مصاحبهInterview tip

وقتی می‌پرسند «چرا تحلیل را روی پایگاه داده عملیاتی اجرا نکنیم؟» این چهار دلیل را بگو: ۱) داده بین ده‌ها سیستم عملیاتی پخش است (data silos) و باید ترکیب شود؛ ۲) اسکیمای خوب برای OLTP برای تحلیل مناسب نیست؛ ۳) کوئری تحلیلی گران است و پاسخ‌گویی به کاربران دیگر را کند می‌کند؛ ۴) دسترسی مستقیم به سیستم‌های عملیاتی به دلایل امنیتی/انطباق ممنوع است.

When asked “why not run analytics on the operational database?”, give these four reasons: 1) data is spread across dozens of operational systems (data silos) and must be combined; 2) a good OLTP schema is a bad analytical schema; 3) analytical queries are expensive and starve other users; 4) direct access to operational systems is forbidden for security/compliance reasons.

زیر ذره‌بینUnder the lens

Product / real-time analytics: سیستم‌هایی مثل Pinot، Druid و ClickHouse بار تحلیلی را داخل محصول کاربر می‌آورند: ورودی زنده، پاسخ کم‌تأخیر. در مقابل، OLAP سنتی ورودی دسته‌ای دارد و برای throughput بهینه شده است.

Product / real-time analytics: systems like Pinot, Druid and ClickHouse bring analytical load inside the user-facing product: live input, low-latency answers. Traditional OLAP instead has batch input and is optimized for throughput.

تصویر مفهومی · OLTP در برابر OLAP — هفت سطر مقایسه و چهار دلیلConcept visual · OLTP vs OLAP — seven rows and four reasons باز کردن در صفحه جدا ↗Open standalone ↗
روایت مدرس از تصویرTeacher narration

مثال فنی برای خواندنِ نمودار: دو پرس‌وجو، دو الگوی دسترسی

وضعیت اولیه: جدول orders صد میلیون ردیف دارد و روی id ایندکس شده است.

اجرای مرحله‌به‌مرحله: WHERE id=42 با ایندکس چند صفحه را می‌خواند؛ SUM(amount) برای کل سال حجم زیادی از ستون مبلغ را اسکن می‌کند.

نتیجه و دلیل: اولی نمونهٔ OLTP و دومی OLAP است؛ ایندکس مناسب اولی لزوماً گزارش دوم را سریع نمی‌کند.

دو ستون سبز و آبی را از روی برچسب‌های زرد وسط بخوانید: هفت سطر از READ تا SIZE. ستون چپ (OLTP) دنیای عملیات است — پیدا کردن چند رکورد با کلید، نوشتن تک‌تک، کاربر نهایی وب و موبایل، کوئری‌های ثابت داخل کد برنامه، تعداد زیاد ولی کوچک، معنای «وضعیت فعلی» و حجم گیگابایت تا ترابایت. ستون راست (OLAP) دنیای تحلیل است — اسکن میلیون‌ها رکورد و تجمیع، ورود دسته‌ای یا جریانی، تحلیلگر داخلی، کوئری اکتشافی، تعداد کم ولی سنگین، معنای «تاریخچه» و حجم ترابایت تا پتابایت.

نوار پایینی جواب سوال مصاحبه‌ای است: چرا تحلیل را روی OLTP اجرا نکنیم؟ چهار جعبه: SILOS (داده در ده‌ها سیستم جدا پخش است)، SCHEMA (اسکیمای خوب عملیاتی، اسکیمای بد تحلیلی است)، COST (اسکن سنگین منابع لازم برای پاسخ به کاربران را مصرف می‌کند) و ACCESS (دسترسی مستقیم اغلب به دلایل امنیتی ممنوع است). جمع‌بندی یک‌خطی پایین تصویر: OLTP برای کارِ روزمره پاسخ می‌دهد، OLAP گذشته را توضیح می‌دهد.

Read the green and blue columns through the yellow center pills: seven rows from READ to SIZE. The left column (OLTP) is the operational world — looking up a few rows by key, writing one row at a time, end users on web and mobile, fixed queries baked into application code, many but tiny queries, the meaning “current state”, and gigabytes to terabytes. The right column (OLAP) is the analytical world — scanning millions of rows and aggregating, bulk or streaming ingest, internal analysts, ad-hoc exploratory queries, few but heavy, the meaning “history”, and terabytes to petabytes.

The bottom strip answers the interview question: why not analyze on the OLTP database? Four boxes: SILOS (data lives in dozens of separate systems), SCHEMA (a good operational schema is a bad analytical one), COST (heavy scans starve live users), and ACCESS (direct access is usually forbidden for security reasons). The one-line takeaway: OLTP serves the present, OLAP explains the past.

انبارداده، دریاچه داده، ETL و Reverse ETLWarehouse, lake, ETL and reverse ETL

انبارداده (Data Warehouse)Data warehouse

انبار داده، اطلاعات را برای گزارش‌گیری منظم آماده می‌کند. دریاچهٔ داده می‌تواند فایل‌ها را با قالب‌های متنوع نگه دارد. ETL یعنی استخراج، تبدیل و بارگذاری؛ در ELT تبدیل پس از بارگذاری انجام می‌شود.

مثال فنی: ساخت جدول قابل‌تحلیل

وضعیت اولیه: سفارش‌ها شامل amount_rial و زمان با منطقهٔ زمانی‌اند.

اجرای مرحله‌به‌مرحله: ETL زمان را به روز گزارش تبدیل می‌کند، واحد مبلغ را یکسان می‌کند و در fact_sales(day, product_id, amount) می‌نویسد.

نتیجه و دلیل: تحلیلگر می‌تواند فروش روزانه را جمع بزند؛ اگر واحد یا منطقهٔ زمانی مبهم باشد، انبار داده فقط خطا را منظم‌تر ذخیره کرده است.

A separate database holding a read-only copy of every operational system’s data, so analysts can run anything without pressuring OLTP. Data arrives via Extract–Transform–Load (ETL): extract from operational databases (periodic dumps or a continuous change stream) → transform into an analysis-friendly schema → clean → load. Swap transform and load and you get ELT.

دریاچه داده (Data Lake)Data lake

دریاچهٔ داده محلِ نگهداریِ داده با قالب‌های متنوع است؛ برای استفاده از آن همچنان به فهرست، کیفیت و قراردادِ داده نیاز داریم.

مثال فنی: فایل خام در دریاچهٔ داده

وضعیت اولیه: رویدادهای وب به‌شکل JSON و تصاویر کالا به‌شکل JPEG در object storage ذخیره‌اند.

اجرای مرحله‌به‌مرحله: یک job فیلد event_time را از JSON می‌خواند و خروجی ستونی می‌سازد؛ تصاویر از مسیر پردازش دیگری می‌روند.

نتیجه و دلیل: فایل‌ها می‌توانند قالب‌های متفاوت داشته باشند؛ برای تحلیل هنوز schema، نسخه و کیفیت هر مجموعه باید مشخص باشد.

مخزن متمرکزی از فایل‌های خام بدون اجبار به فرمت/اسکیمای خاص: رکوردهای پایگاه‌داده‌ای با فرمت Avro یا Parquet، اما می‌تواند متن، تصویر، ویدیو و... هم باشد. معمولاً ارزان‌تر از ذخیره‌سازی رابطه‌ای چون روی object storage می‌نشیند. اصل معروف: «sushi principle: raw data is better» — داده خام را نگه دار تا هر مصرف‌کننده خودش تبدیل کند.

A central repository of raw files with no enforced format/schema: database records as Avro or Parquet, but also text, images, video and more. Usually cheaper than relational storage because it sits on object storage. The famous rule: “sushi principle: raw data is better” — keep data raw so each consumer transforms it their own way.

HTAP و Reverse ETLand reverse ETL

HTAP می‌کوشد بارِ عملیاتی و تحلیلی را نزدیک‌تر کند. Reverse ETL نتیجهٔ آمادهٔ تحلیل را به ابزارهای عملیاتی برمی‌گرداند؛ این دو کار متفاوت‌اند.

مثال فنی: برگرداندن نتیجهٔ تحلیل به عملیات

وضعیت اولیه: انبار داده برای مشتری 17 مجموع خرید ۹۰ روزه را 8000 محاسبه کرده است.

اجرای مرحله‌به‌مرحله: job مشتریان با مجموع بالای 5000 را با کلید customer_id به CRM منتقل می‌کند و زمان محاسبه را هم می‌فرستد.

نتیجه و دلیل: CRM از برچسب آماده استفاده می‌کند؛ این Reverse ETL است. برچسب تا اجرای بعدی به‌روز نمی‌شود.

  • HTAP (Hybrid Transactional/Analytical Processing): هدفش اجرای هر دو بار در یک سیستم است، اما در عمل داخل خودش یک موتور OLTP و یک موتور تحلیلیِ پشت یک رابط مشترک دارد؛ پس جایگزین انبارداده نمی‌شود.
  • Reverse ETL: خروجی سیستم‌های تحلیلی به سیستم‌های عملیاتی برمی‌گردد؛ مثلاً مدل ML آموزش‌دیده به پروداکشن می‌رود تا پیشنهاد «کسانی که X خریدند Y هم خریدند» بسازد.
  • HTAP (Hybrid Transactional/Analytical Processing): aims to serve both workloads in one system, but internally it is an OLTP engine plus an analytical engine behind one interface — so it does not replace the warehouse.
  • Reverse ETL: analytical output flows back into operational systems; e.g. a trained ML model goes to production to power “customers who bought X also bought Y”.
فقط اسمش را بدانNames only

مفاهیمی مثل DataOps، feature engineering و ابزارهایی مثل Fivetran / Airbyte / Singer فقط لازم است نامشان را بدانی و جایگاهشان در مسیر داده؛ عمق ابزاری‌شان موضوع مصاحبه این فصل نیست.

Concepts like DataOps and feature engineering, and tools like Fivetran / Airbyte / Singer, are name-and-place-in-the-pipeline knowledge; their tooling depth is not this chapter’s interview topic.

نمودار ۱ — جریان داده از OLTP تا تحلیل و بازگشت به عملیاتDiagram 1 — dataflow from OLTP to analytics and back to operations

نمودار ۱ · جریان داده — از سیستم‌های عملیاتی تا مصرف‌کننده‌های تحلیلیDiagram 1 · Dataflow — from operational systems to analytical consumers باز کردن در صفحه جدا ↗Open standalone ↗
روایت مدرس از نمودارTeacher narration

مثال فنی برای خواندنِ نمودار: ساخت جدول قابل‌تحلیل

وضعیت اولیه: سفارش‌ها شامل amount_rial و زمان با منطقهٔ زمانی‌اند.

اجرای مرحله‌به‌مرحله: ETL زمان را به روز گزارش تبدیل می‌کند، واحد مبلغ را یکسان می‌کند و در fact_sales(day, product_id, amount) می‌نویسد.

نتیجه و دلیل: تحلیلگر می‌تواند فروش روزانه را جمع بزند؛ اگر واحد یا منطقهٔ زمانی مبهم باشد، انبار داده فقط خطا را منظم‌تر ذخیره کرده است.

این نمودار را مثل سه خط تولید موازی بخوانید که در پنج ستون جلو می‌روند: OLTP Sources، Ingest، Analytics Store، Consumers و Back to Ops. ردیف بالا مسیر دسته‌ای است: Orders DB (سیستم مرجع) ← ETL Jobs (استخراج و تبدیل) ← Warehouse (کپی فقط‌خواندنی با اسکیمای پاک‌شده) ← BI Dashboards با SQL دل‌خواه.

ردیف میانی مسیر داده خام است: External SaaS ← Connectors ← Data Lake (فایل خام بدون اسکیما) ← Data Science که روی همان داده خام مدل می‌سازد.

ردیف پایین مسیر زنده است: Backend Svcs ← Event Stream (لاگ کافکا) ← Real-Time OLAP مثل ClickHouse ← Product UI که رویدادها را در چند ثانیه مصرف می‌کند.

و تنها فلش افقی چین‌چین: از Data Science به Prod Services با برچسب reverse ETL — مدل آموزش‌دیده به مسیر عملیاتی برمی‌گردد. درس نمودار: هر سه مسیر داده «مشتق‌شده» می‌سازند؛ تحلیل، کپی چیزی است که جای دیگر ساخته شده.

Read this diagram as three parallel production lines across five stages: OLTP Sources, Ingest, Analytics Store, Consumers and Back to Ops. The top row is the batch path: Orders DB (system of record) → ETL Jobs (extract and transform) → Warehouse (read-only copy with a curated schema) → BI Dashboards over ad-hoc SQL.

The middle row is the raw-data path: External SaaS → Connectors → Data Lake (schema-less raw files) → Data Science, which trains models on that same raw data.

The bottom row is the live path: Backend Svcs → Event Stream (Kafka log) → Real-Time OLAP such as ClickHouse → Product UI, consuming events within seconds.

And the single dashed horizontal arrow: from Data Science to Prod Services, labelled reverse ETL — the trained model returns to the operational path. The lesson: all three paths produce derived data; analytics is a copy of something created elsewhere.

۲2 سیستم مرجع در برابر داده مشتق‌شدهSystem of record vs derived data

ایده کلیدیKey idea

سیستم مرجع محل نگهداری نسخهٔ معتبر داده است. کش، ایندکس جست‌وجو و گزارش‌ها معمولاً از آن ساخته می‌شوند؛ اگر از بین بروند، باید بتوان آن‌ها را دوباره ساخت.

مثال فنی: بازسازی دادهٔ مشتق‌شده

وضعیت اولیه: مرجع کالا P7 را با version=12 نگه داشته؛ ایندکس جست‌وجو خراب شده است.

اجرای مرحله‌به‌مرحله: snapshot مرجع تا موقعیت لاگ 500 وارد ایندکس تازه می‌شود و سپس تغییرهای پس از 500 اعمال می‌شوند.

نتیجه و دلیل: با مرز snapshot و لاگِ هماهنگ می‌توان ایندکس را بازسازی کرد؛ صرفِ کپی قدیمی ممکن است تغییرهای حین کپی را جا بیندازد.

System of record (source of truth): where fresh data is written first; each fact is stored exactly once (usually normalized), and if two systems disagree, this system’s value is correct by definition.

Derived data: the result of transforming data that exists elsewhere. If lost, it can be rebuilt from the record: caches, search indexes, materialized views, denormalized values, even a trained ML model.

زیر ذره‌بینUnder the lens
  • داده مشتق‌شده از نظر اطلاعاتی اضافه است اما برای کارایی خواندن حیاتی: از یک منبع، چند نمای متفاوت می‌سازی.
  • سیستم‌های تحلیلی معمولاً مشتق‌شده‌اند چون مصرف‌کننده داده‌ای‌اند که جای دیگر ساخته شده.
  • خود ابزار تعیین‌کننده نیست: این نوع استفاده تو در معماری است که چیزی را «مرجع» یا «مشتق» می‌کند.
  • مسئله اصلی: وقتی مرجع تغییر می‌کند، همه داده‌های مشتق‌شده باید به‌روز شوند → راه‌حل: pipeline داده (فصل ۱۱).
  • Derived data is informationally redundant yet vital for read performance: one source, many views.
  • Analytical systems are usually derived — they consume data created elsewhere.
  • The tool doesn’t decide: it is how you use it in the architecture that makes something a record or derived.
  • The core problem: when the record changes, all derived data must catch up → the answer is a data pipeline (Chapter 11).

نمودار ۲ — مسیر نوشتن، مسیر تغییر، مسیر خواندنDiagram 2 — write path, change path, read path

نمودار ۲ · معماری — مرجع و سیستم‌های مشتق‌شدهDiagram 2 · Architecture — record and derived systems باز کردن در صفحه جدا ↗Open standalone ↗
روایت مدرس از نمودارTeacher narration

مثال فنی برای خواندنِ نمودار: پایگاه داده، کش و ایندکس چه می‌کنند؟

وضعیت اولیه: قیمت کالای P7 در مرجع 120 است؛ در کش هنوز 100 مانده است.

اجرای مرحله‌به‌مرحله: API خرید قیمت معتبر را از مسیر مرجع می‌گیرد؛ مصرف‌کنندهٔ تغییر، کش و ایندکس جست‌وجو را به نسخهٔ 120 می‌رساند.

نتیجه و دلیل: کش برای سرعت و ایندکس برای جست‌وجوست؛ هیچ‌کدام بدون قرارداد مشخص، مرجع تأیید قیمت خرید نیستند.

خط افقی وسط، مسیر نوشتن است: Users ← API Service ← System of Record (پرایمری با برچسب source of truth). هر داده واقعی اول اینجا می‌نشیند.

ردیف بالا مسیر خواندن است: API Service با cache lookup به Cache و با search query به Search Index می‌رود — هر دو با برچسب derived، ساخته‌شده برای سرعت خواندن نه نگه‌داشتن حقیقت.

فلش‌های چین‌چین مسیر تغییرند: CDC events از مرجع به Change Capture، بعد refresh/evict به کش، index update به ایندکس و recompute به Materialized Views. و تحلیلگران روی همین نماها کوئری می‌زنند، نه روی پایگاه داده زنده.

نکته اصلی: مرجع که عوض شود همه‌چیز باید دنبالش به‌روز شود. ناسازگاری موقت قابل قبول است، از دست رفتن دائمی داده مرجع هرگز.

The middle horizontal line is the write path: Users → API Service → System of Record (primary, labelled source of truth). Every real datum lands here first.

The top row is the read path: API Service issues a cache lookup to the Cache and a search query to the Search Index — both labelled derived, built for read speed, not for holding truth.

The dashed arrows are the change path: CDC events flow from the record into Change Capture, then refresh/evict to the cache, index update to the index, and recompute to Materialized Views. Analysts query those views — never the live database.

The point: when the record changes, everything must follow. Temporary inconsistency is acceptable; permanent loss of record data never is.

نکته مصاحبهInterview tip

اگر گفتند «کش شما source of truth است»، جواب قوی این است: کش/ایندکس مشتق‌شده‌اند، پس باید قابل بازسازی باشند و مکانیزم انتشار تغییر (CDC، رویداد یا pipeline) داشته باشند.

If someone calls the cache the source of truth, push back: caches/indexes are derived, so they must be rebuildable and fed by a change-propagation mechanism (CDC, events or a pipeline).

نمودار وضعیت — چرخه عمر یک دادهState diagram — life of a datum

نمودار وضعیت — از ساخت تا حذفState machine — from creation to deletion باز کردن در صفحه جدا ↗Open standalone ↗
روایت مدرس از نمودارTeacher narration

مثال فنی برای خواندنِ نمودار: بازسازی دادهٔ مشتق‌شده

وضعیت اولیه: مرجع کالا P7 را با version=12 نگه داشته؛ ایندکس جست‌وجو خراب شده است.

اجرای مرحله‌به‌مرحله: snapshot مرجع تا موقعیت لاگ 500 وارد ایندکس تازه می‌شود و سپس تغییرهای پس از 500 اعمال می‌شوند.

نتیجه و دلیل: با مرز snapshot و لاگِ هماهنگ می‌توان ایندکس را بازسازی کرد؛ صرفِ کپی قدیمی ممکن است تغییرهای حین کپی را جا بیندازد.

این ماشین وضعیت را مثل خط زمانی زندگی یک «داده» بخوانید. ردیفِ بالا (Authoritative data): Created ← Recorded (مرجع، source of truth) ← Change Captured. از آنجا دو فلش به ردیفِ وسط (Derived copies) می‌روند: refresh به کپی‌های مشتق (بازسازی‌شدنی) و ETL pipeline به کپی تحلیلی (فقط‌خواندنی). درس اصلی در ردیفِ پایین (End of life) است: Deleted با برچسب حق فراموش شدن — حذف فقط پاک کردن رکورد نیست، باید به همه کپی‌های مشتق‌شده هم برسد، و همین کار با لاگ‌های تغییرناپذیر را سخت می‌کند.

Read this state machine as the timeline of one datum’s life. Top lane (Authoritative data): Created → Recorded (the record, source of truth) → Change Captured. Two arrows then drop to the middle lane (Derived copies): refresh into derived copies (rebuildable) and an ETL pipeline into the analytical copy (read-only). The real lesson is the bottom lane (End of life): Deleted, tagged with the right to be forgotten — deletion is not just dropping the record; it must reach every derived copy, which is exactly what immutable logs make hard.

۳3 کلاود در برابر خودمیزبانیCloud vs self-hosting

ایده کلیدیKey idea

انتخاب بین سرویس ابری و میزبانی شخصی یعنی تصمیم بگیریم کدام مسئولیت‌ها را خودمان انجام دهیم و کدام را به ارائه‌دهنده بسپاریم. هزینه، مهارت تیم و میزان کنترل در این تصمیم اثر دارند.

مثال فنی: مرز مسئولیت در میزبانی

وضعیت اولیه: یک پایگاه داده به patch، backup و آزمون restore نیاز دارد.

اجرای مرحله‌به‌مرحله: در خودمیزبانی تیم این کارها را اجرا می‌کند؛ در سرویس مدیریت‌شده بخشی از عملیات به ارائه‌دهنده سپرده می‌شود، اما schema و مجوزهای برنامه همچنان با تیم است.

نتیجه و دلیل: مدیریت‌شده بودن مسئولیت را جابه‌جا می‌کند؛ وجود backup بدون آزمون بازیابی، زمان بازگشت سرویس را معلوم نمی‌کند.

This is a “build or buy” debate — ultimately a business decision. The rule of thumb: build in-house what is your competitive advantage; hand the undifferentiated commodity parts to a vendor.

طیف برون‌سپاریThe outsourcing spectrum

برون‌سپاری صفر و یک نیست: از نوشتن و اجرای همه‌چیز توسط تیم تا استفاده از یک نرم‌افزار کاملاً آماده، چند سطح مختلف داریم.

مثال فنی: سه راه ساخت جست‌وجو

وضعیت اولیه: نیاز محصول جست‌وجوی متن با غلط املایی و رتبه‌بندی است.

اجرای مرحله‌به‌مرحله: تیم می‌تواند موتور بنویسد، موتور آماده را روی سرور خودش اجرا کند یا API مدیریت‌شده بخرد؛ در هر سه راه کیفیت نتایج باید با همان مجموعهٔ آزمون سنجیده شود.

نتیجه و دلیل: هزینهٔ توسعه، عملیات و وابستگی متفاوت است؛ خرید API به‌خودی‌خود کیفیت جست‌وجوی محصول را تضمین نمی‌کند.

On one end: bespoke software you write and run yourself → packaged self-hosted software (MySQL on your own server, on-prem or IaaS) → and on the other end: cloud/SaaS services you only consume through an API.

کی کلاود به‌صرفه است؟When does cloud win?

ابر زمانی به‌صرفه‌تر می‌شود که انعطاف منابع یا کاهش کار عملیاتی، هزینهٔ اجاره را جبران کند. باید هزینهٔ کل را دید: زیرساخت، نیروی انسانی، انتقال داده و خرابی‌ها.

مثال فنی: حساب هزینهٔ ظرفیت فصلی

وضعیت اولیه: فرض کنید بار عادی به ۲ worker و حراجِ دو روزه به ۲۰ worker نیاز دارد.

اجرای مرحله‌به‌مرحله: در مدل ساعتی ۱۸ worker اضافه فقط همان دو روز فعال‌اند؛ هزینهٔ ذخیره، شبکه و سرویس‌های ثابت هم جدا محاسبه می‌شود.

نتیجه و دلیل: کشسانی می‌تواند هزینهٔ ظرفیت بیکار را کم کند؛ از این مثال نمی‌توان نتیجه گرفت ابر برای هر بار دائمی ارزان‌تر است.

  • به‌سود کلاود: راه‌اندازی سیستمی که بلد نیستی؛ بار کاری بسیار متغیر؛ سرعت حرکت و تمرکز تیم روی مسائل سطح بالاتر.
  • به‌سود خودمیزبانی: تجربه عملیاتی داری و بار قابل پیش‌بینی است؛ کنترل کامل می‌خواهی (مثل high-frequency trading)؛ می‌خواهی برای بار خاصت تیون کنی.
  • Cloud wins: you can’t operate the system yourself; the workload is highly variable; you want speed and the team focused on higher-level problems.
  • Self-hosting wins: you have operating experience and predictable load; you need full control (e.g. high-frequency trading); you want to tune for your specific workload.
ریسک‌های بزرگ کلاودBig cloud risks
  • کنترلی نداری: نبود قابلیت، قطعی سرویس، دشواری دیباگ.
  • Vendor lock-in: بدون API استاندارد، هزینه مهاجرت بالاست.
  • ریسک ژئوپلیتیک: تحریم یا تنش سیاسی می‌تواند دسترسی را قطع کند.
  • اعتماد به فروشنده برای امنیت داده؛ انطباق حریم خصوصی پیچیده‌تر می‌شود.
  • No control: missing features, outages, hard debugging.
  • Vendor lock-in: without a standard API, migration is expensive.
  • Geopolitical risk: sanctions or tension can cut off access.
  • You trust the vendor with data security; privacy compliance gets harder.
تصویر مفهومی · طیف برون‌سپاری — از bespoke تا SaaS، کی کدام می‌بردConcept visual · the outsourcing spectrum — bespoke to SaaS, who wins when باز کردن در صفحه جدا ↗Open standalone ↗
روایت مدرس از تصویرTeacher narration

مثال فنی برای خواندنِ نمودار: سه راه ساخت جست‌وجو

وضعیت اولیه: نیاز محصول جست‌وجوی متن با غلط املایی و رتبه‌بندی است.

اجرای مرحله‌به‌مرحله: تیم می‌تواند موتور بنویسد، موتور آماده را روی سرور خودش اجرا کند یا API مدیریت‌شده بخرد؛ در هر سه راه کیفیت نتایج باید با همان مجموعهٔ آزمون سنجیده شود.

نتیجه و دلیل: هزینهٔ توسعه، عملیات و وابستگی متفاوت است؛ خرید API به‌خودی‌خود کیفیت جست‌وجوی محصول را تضمین نمی‌کند.

نوار سه‌تکه بالا طیف برون‌سپاری است: BESPOKE صورتی (خودت می‌نویسی و اجرا می‌کنی) ← SELF-HOSTED زرد (نرم‌افزار آماده روی سرور خودت) ← CLOUD سبز (مصرف از طریق API). زیرنویس‌ها جهت را می‌گویند: به‌سمت راست کنترل کم و راحتی زیاد می‌شود. قاعده سرانگشتی بالای تصویر: چیزی که مزیت رقابتی توست بساز، بقیه کالایی را بخر.

دو جعبه وسط شرط برد هر سمت را می‌گویند: کلاود وقتی می‌برد که بلد نیستی اجرایش کنی، بار پرنوسان است و سرعت مهم‌تر از کنترل است؛ خودمیزبانی وقتی که تجربه عملیاتی داری، بار قابل پیش‌بینی است و کنترل یا تیون خاص مزیت توست. نوار پایینی چهار ریسک کلاود است — نبود کنترل، قفل فروشنده، ژئوپلیتیک و اعتماد — و جمله طلایی عملیات: برنامه‌ریزی ظرفیت تبدیل به برنامه‌ریزی مالی می‌شود.

The three-segment bar is the outsourcing spectrum: pink BESPOKE (you write it, you run it) → yellow SELF-HOSTED (packaged software on your servers) → green CLOUD (consume through an API). The captions give the direction: control decreases rightward, convenience grows. The rule of thumb on top: build what is your competitive edge, buy the commodity rest.

The two middle boxes state each side’s winning condition: cloud wins when you cannot operate the system, the workload swings, and speed beats control; self-hosting wins when you have ops experience, load is predictable, and control or special tuning is your edge. The bottom strip lists four cloud risks — no control, lock-in, geopolitics, trust — and the ops golden line: capacity planning becomes financial planning.

Cloud Native و جدایی ذخیره‌سازی از محاسبهCloud native and storage/compute disaggregation

  • Cloud Native: معماری طراحی‌شده از پایه برای سرویس‌های ابری؛ نه فقط «نرم‌افزار قدیمی روی VM».
  • لایه‌بندی: سرویس‌های سطح پایین مثل Object Storage فایل‌های بزرگ را نگه می‌دارند؛ سرویس‌های بالاتر (مثل Snowflake) روی آن‌ها ساخته می‌شوند.
  • جدایی (disaggregation): ذخیره در S3، محاسبه جای دیگر؛ پس دیسک محلی ماشین ابری دیگر «ماندگار» نیست — یک کش موقت است.
  • تله دیسک مجازی: EBS رفتار دیسک را روی شبکه شبیه می‌کند؛ هر I/O یک فراخوانی شبکه است.
  • Multitenancy: سخت‌افزار مشترک بین مشتریان — بهره‌وری بالاتر، اما نیازمند جداسازی دقیق کارایی و امنیت.
  • Cloud native: architecture designed from the ground up for cloud services — not “legacy software on a VM”.
  • Layering: low-level services like object storage hold large files; higher services (e.g. Snowflake) build on top.
  • Disaggregation: storage in S3, compute elsewhere; so a cloud VM’s local disk is no longer “durable” — it is a temporary cache.
  • Virtual-disk trap: EBS emulates a disk over the network; every I/O is a network call.
  • Multitenancy: hardware shared across customers — better utilization, but performance and security isolation must be engineered precisely.
عملیات در عصر کلاودOps in the cloud era

جدا کردن ذخیره‌سازی از محاسبه یعنی داده در یک لایه بماند و تعداد پردازنده‌ها مستقل از آن تغییر کند. افزایش توان پردازش دیگر الزاماً به معنی جابه‌جایی همهٔ داده نیست.

مثال فنی: پردازش جدا از فایل‌ها

وضعیت اولیه: گزارش روی 10 TB فایل فروش در مخزن مشترک اجرا می‌شود.

اجرای مرحله‌به‌مرحله: برای گزارش آخر ماه ۲۰ worker فایل‌ها را تقسیم می‌کنند؛ پس از پایان خاموش می‌شوند و فایل‌ها باقی می‌مانند.

نتیجه و دلیل: ظرفیت compute مستقل از حجم داده تغییر می‌کند؛ توان خواندن مخزن و انتقال شبکه هنوز می‌تواند گلوگاه باشد.

The goal is unchanged (reliable service delivery) but the tools changed. The book’s golden line: “capacity planning becomes financial planning, and performance optimization becomes cost optimization.”

نمودار ۳ — معماری Cloud NativeDiagram 3 — cloud-native architecture

نمودار ۳ · معماری — جدایی Storage و ComputeDiagram 3 · Architecture — storage/compute separation باز کردن در صفحه جدا ↗Open standalone ↗
روایت مدرس از نمودارTeacher narration

مثال فنی برای خواندنِ نمودار: پردازش جدا از فایل‌ها

وضعیت اولیه: گزارش روی 10 TB فایل فروش در مخزن مشترک اجرا می‌شود.

اجرای مرحله‌به‌مرحله: برای گزارش آخر ماه ۲۰ worker فایل‌ها را تقسیم می‌کنند؛ پس از پایان خاموش می‌شوند و فایل‌ها باقی می‌مانند.

نتیجه و دلیل: ظرفیت compute مستقل از حجم داده تغییر می‌کند؛ توان خواندن مخزن و انتقال شبکه هنوز می‌تواند گلوگاه باشد.

بیشتر اجزا داخل قاب بزرگ Cloud Region: multitenant shared hardware نشسته‌اند. از بیرون: Clients ← Data Service API (لایه بی‌حالت با صورتحساب مصرفی) ← Elastic Compute (ارتجاعی، ephemeral). بالای محاسبه، Local Disk فقط «بلوک‌های داغ» را کش می‌کند و با خرابی می‌میرد — هرگز جای ماندگاری نیست. سمت راست دو مقصد ماندگارند: Object Storage برای بلوک‌های بزرگ (durable) و Metadata Service برای مقادیر کوچک (low latency). فلش چین‌چین پایینی (legacy path) به Virtual Disk همان جایگزین قدیمی است. درس: محاسبه گذراست، داده ماندگار است، و می‌توانی بدون دست زدن به داده محاسبه را بالا و پایین ببری.

Most components sit inside the large Cloud Region: multitenant shared hardware frame. From outside: Clients → Data Service API (a stateless tier with metered billing) → Elastic Compute (elastic, ephemeral). Above compute, the Local Disk caches only “hot blocks” and dies with failure — never the place of durability. On the right sit the two durable destinations: Object Storage for large blocks (durable) and a Metadata Service for small values (low latency). The dashed arrow at the bottom (legacy path) to the Virtual Disk is the old alternative. The lesson: compute is transient, data is durable, and you can scale compute up and down without touching the data.

۴4 سیستم توزیع‌شده در برابر تک‌ماشینDistributed vs single-machine

ایده کلیدیKey idea

روی یک ماشین، هماهنگی ساده‌تر است؛ روی چند ماشین، می‌توان ظرفیت و تحمل خرابی بیشتری ساخت، اما شبکه و هماهنگی به مسئله اضافه می‌شوند.

مثال فنی: آیا یک ماشین کافی است؟

وضعیت اولیه: دادهٔ فعال 80 GB است و در حافظهٔ سرور 128 GB جا می‌گیرد؛ آزمون بار هم هدف پاسخ را تأمین می‌کند.

اجرای مرحله‌به‌مرحله: افزودن شارد، مسیریابی و هماهنگی را وارد مسیر می‌کند، بی‌آنکه هنوز کمبود ظرفیت اثبات شده باشد.

نتیجه و دلیل: فعلاً همان ماشین ساده‌تر است؛ replica برای تحمل خرابی می‌تواند نیاز جداگانه‌ای باشد، حتی وقتی sharding لازم نیست.

Don’t rush. Doing the job on one machine is usually far simpler and cheaper. With single-node databases like DuckDB, SQLite and KùzuDB, many workloads fit on one node.

چرا اصلاً توزیع کنیم؟ (دلایل واقعی)Why distribute at all? (real reasons)

توزیع کردن باید مسئلهٔ مشخصی را حل کند: کمبود ظرفیت، نیاز به ادامهٔ کار هنگام خرابی یا نزدیک کردن داده به کاربران. هر دلیل، طراحی متفاوتی می‌خواهد.

مثال فنی: توزیع برای حل یک محدودیت مشخص

وضعیت اولیه: آرشیو 40 TB است و هر سرور فقط 10 TB فضای قابل‌استفاده دارد.

اجرای مرحله‌به‌مرحله: کلیدها بین چند shard تقسیم می‌شوند و برای هر shard نسخهٔ پشتیبانِ زنده در نظر گرفته می‌شود.

نتیجه و دلیل: sharding ظرفیت را زیاد می‌کند و replication تحمل خرابی را؛ این دو وظیفه را نباید با هم اشتباه گرفت.

  • توزیع ذاتی: تعامل دو کاربر با دستگاه متفاوت ناگزیر از شبکه می‌گذرد.
  • تحمل خرابی / دسترس‌پذیری: افتادن یک ماشین نباید سرویس را بخواباند.
  • مقیاس‌پذیری: حجم یا محاسبه از ظرفیت یک ماشین بیشتر شود.
  • تأخیر: کاربران جهانی ← سرور نزدیک هر کاربر.
  • ارتجاع: پرداخت فقط به‌ازای منابع مصرفی در اوج و فرود بار.
  • سخت‌افزار تخصصی، انطباق قانونی (data residency) و پایداری انرژی.
  • Inherent distribution: two users on different devices must communicate over a network.
  • Fault tolerance / availability: losing one machine must not stop the service.
  • Scalability: volume or compute outgrows one machine.
  • Latency: global users → a server near each user.
  • Elasticity: paying only for consumed resources through peaks and troughs.
  • Specialized hardware, legal data residency, and energy sustainability.

هزینه‌های توزیع + میکروسرویس و ServerlessCosts of distribution + microservices and serverless

با جدا کردن سرویس‌ها، هر درخواست ممکن است از چند اتصال شبکه عبور کند. باید تأخیر، خطا، تکرار درخواست و هزینهٔ اجرای هر بخش را هم حساب کنیم.

مثال فنی: ثبت موفق، پاسخ گم‌شده

وضعیت اولیه: سرویس سفارش درخواست r7 را ثبت می‌کند، اما پاسخ در شبکه گم می‌شود.

اجرای مرحله‌به‌مرحله: کلاینت همان r7 را دوباره می‌فرستد؛ قید یکتایی روی شناسهٔ درخواست اجازهٔ سفارش دوم نمی‌دهد و نتیجهٔ قبلی برمی‌گردد.

نتیجه و دلیل: timeout شکست قطعی عملیات نیست؛ تولید شناسهٔ تازه در هر retry می‌تواند دو سفارش واقعی بسازد.

  • هر درخواست شبکه ممکن است timeout بخورد؛ نمی‌دانی سرویس درخواست را گرفته یا نه و «تکرار کورکورانه» ممکن است ناامن باشد (فصل ۹).
  • فراخوانی شبکه به‌مراتب کندتر از فراخوانی تابع در همان فرآیند است؛ گاهی جابه‌جایی «محاسبه» به سمت داده سریع‌تر است. بیشتر گره ≠ سریع‌تر.
  • دیباگ سخت می‌شود ← Observability: متریک، لاگ و ردیابی با OpenTelemetry، Zipkin، Jaeger.
  • وقتی هر سرویس پایگاه داده خودش را دارد، سازگاری داده بین سرویس‌ها مشکل خود برنامه می‌شود.
  • Every network request can time out; you don’t know if the service got it, and blind retries may be unsafe (Chapter 9).
  • A network call is far slower than an in-process function call; sometimes moving compute to the data is faster. More nodes ≠ faster.
  • Debugging gets hard → observability: metrics, logs and tracing with OpenTelemetry, Zipkin, Jaeger.
  • When each service owns its database, cross-service data consistency becomes the application’s own problem.
میکروسرویس و Serverless در یک نگاهMicroservices and serverless at a glance
  • میکروسرویس: هر سرویس یک هدف، یک API و یک تیم؛ معمولاً هر سرویس پایگاه داده خودش را دارد. مزیت: به‌روزرسانی مستقل. هزینه: تست، استقرار، مانیتورینگ و تکامل API.
  • نکته طلایی: «میکروسرویس راه‌حل فنی برای یک مسئله انسانی است» — در شرکت کوچک سربار بی‌دلیل است.
  • Serverless / FaaS: پرداخت به‌ازای اجرا؛ اما محدودیت زمان تابع، محیط محدود و cold start.
  • Microservices: one goal, one API and one team per service; usually each service owns its database. Benefit: independent deploys. Cost: testing, deployment, monitoring and API evolution.
  • Golden line: “microservices are a technical solution to a human problem” — in a small company they are needless overhead.
  • Serverless / FaaS: pay per execution; but function time limits, constrained runtimes and cold starts.

نمودار ۴ — تصمیم «کی توزیع کنیم؟»Diagram 4 — “when to distribute?”

نمودار ۴ · تصمیم — اول تک‌ماشین، بعد توزیع حداقلیDiagram 4 · Decision — single-node first, then minimal distribution باز کردن در صفحه جدا ↗Open standalone ↗
روایت مدرس از نمودارTeacher narration

مثال فنی برای خواندنِ نمودار: توزیع برای حل یک محدودیت مشخص

وضعیت اولیه: آرشیو 40 TB است و هر سرور فقط 10 TB فضای قابل‌استفاده دارد.

اجرای مرحله‌به‌مرحله: کلیدها بین چند shard تقسیم می‌شوند و برای هر shard نسخهٔ پشتیبانِ زنده در نظر گرفته می‌شود.

نتیجه و دلیل: sharding ظرفیت را زیاد می‌کند و replication تحمل خرابی را؛ این دو وظیفه را نباید با هم اشتباه گرفت.

از New Service شروع کن و با فلش start here به Single Node First برو (Postgres, DuckDB, SQLite — ساده‌تر و ارزان‌تر). با رشد، به تصمیم Limit Reached? می‌رسی (حجم، نرخ درخواست، تأخیر): اگر نه ← Stay Single-Node (مقیاس عمودی و تیون کوئری)؛ اگر بله ← Name the Driver (دسترس‌پذیری، مقیاس، تأخیر، قانون) و بعد Distribute با حداقل دامنه لازم. ناحیه آخر قیمت کار است: توزیع حالت‌های شکست تازه می‌آورد (timeout, retries) و باید بودجه مقابله بگذاری — idempotency و ردیابی — که هرگز رایگان نیست. قاعده: اول تک‌ماشین، بعد توزیع حداقلی، فقط با اسم‌آوردن دلیل.

Start at New Service and follow start here to Single Node First (Postgres, DuckDB, SQLite — simpler and cheaper). As you grow you hit the Limit Reached? decision (volume, QPS, latency): if no → Stay Single-Node (scale up, tune queries); if yes → Name the Driver (availability, scale, latency, legal) and then Distribute with the minimal necessary scope. The last zone shows the price: distribution introduces new failure modes (timeout, retries) and you must budget mitigation — idempotency and tracing — which is never free. The rule: single-node first, then minimal distribution, only with a named reason.

نکته مصاحبهInterview tip

وقتی از «retry» حرف می‌زنی، حتماً کلمه idempotency را بیاور: تکرار یک درخواست ناموفق شبکه می‌تواند یعنی «دو بار کسر شد». کلید idempotent پاسخ مهندسی به همین محدودیت ذاتی سیستم توزیع‌شده است.

When you mention “retry”, always bring the word idempotency: repeating a failed network request can mean “charged twice”. The idempotent key is the engineering answer to this inherent distributed-systems limit.

۵5 داده، قانون و جامعه (خلاصه)Data, law and society (summary)

ایده کلیدیKey idea

معماری داده فقط موضوع سرعت و ظرفیت نیست؛ باید روشن باشد چه اطلاعاتی جمع می‌شود، چه کسی آن را می‌بیند و چگونه حذف یا اصلاح می‌شود.

مثال فنی: حذف در چند نسخه

وضعیت اولیه: دادهٔ مشتری 17 در مرجع، ایندکس و فایل خروجی گزارش کپی شده است.

اجرای مرحله‌به‌مرحله: جریان حذف با همین شناسه مقصدها را دنبال می‌کند؛ وضعیت حذف، زمان نگهداری و محدودیت backup نیز ثبت می‌شوند.

نتیجه و دلیل: حذف یک ردیف به‌معنی حذف همهٔ کپی‌ها نیست؛ دامنه و الزام نگهداری باید برای همین کاربرد بررسی شود.

Architecture is not shaped by technical goals alone; users’ rights enter the equation too.

  • GDPR (از ۲۰۱۸)، CCPA و EU AI Act: حقوقی مثل «حق فراموش شدن» (right to be forgotten).
  • چالش فنی: حذف داده از میان فایل append-only غیرقابل‌تغییر، و از داده‌های مشتق‌شده مثل داده آموزش مدل ML؟
  • انطباق مبهم است: مقررات اصول سطح‌بالای تفسیرپذیر می‌دهند، نه تکنولوژی خاص.
  • Data Minimization (Datensparsamkeit): در برابر فلسفه «big data» که می‌گوید همه‌چیز را نگه دار. هزینه نگهداری فقط قبض S3 نیست: ریسک نشت، آبرو، جریمه و هزینه حقوقی هم هست.
  • در پرداخت: PCI برای کارت و SOC 2 برای فروشندگان نرم‌افزار — با ممیزی‌های دوره‌ای مستقل.
  • GDPR (since 2018), CCPA and the EU AI Act: rights such as the right to be forgotten.
  • Technical challenge: deleting data from the middle of an immutable append-only file — and from derived data like ML training sets?
  • Compliance is vague: regulations give interpretable high-level principles, not specific technology.
  • Data minimization (Datensparsamkeit) vs the “big data” philosophy of keeping everything. Retention cost isn’t just the S3 bill: breach risk, reputation, fines and legal cost count too.
  • In payments: PCI for cards and SOC 2 for software vendors — with periodic independent audits.
نقشه فصل · همه تریدآف‌های فصل ۱ در یک نگاهChapter map · every Chapter 1 trade-off at a glance باز کردن در صفحه جدا ↗Open standalone ↗
روایت مدرس از نقشه فصلChapter-map narration

مثال فنی برای خواندنِ نمودار: مسیر یک سفارش در سه مخزن

وضعیت اولیه: سفارش id=42 با مبلغ 500 در PostgreSQL ثبت شده است.

اجرای مرحله‌به‌مرحله: رویداد تغییر، نسخهٔ نمایش را در Redis و سند جست‌وجو را در ایندکس به‌روز می‌کند. گزارش شبانه مبلغ را جمع می‌زند.

نتیجه و دلیل: خرابی Redis سفارش را حذف نمی‌کند؛ کش از مرجع بازسازی می‌شود. تأخیر انتقال می‌تواند نمایش را موقتاً قدیمی کند.

مرکز نقشه تز فصل است: راه‌حل نیست، فقط تریدآف است. سه یال بالا دنیای داده‌اند: OLTP در برابر OLAP (داده کجا ساخته و کجا تحلیل می‌شود)، مرجع در برابر مشتق‌شده (حقیقت کجاست و کپی‌ها چگونه به‌روز می‌مانند) و انبار در برابر دریاچه (تحلیل روی کپی پاک‌شده یا فایل خام).

سه یال پایین تصمیم‌های معماری‌اند: کلاود در برابر خودمیزبانی (بساز یا بخر)، تک‌ماشین در برابر توزیع‌شده (اول تک‌ماشین، توزیع فقط با دلیل نام‌برده) و داده در برابر قانون (حق فراموش شدن و کمینه‌سازی در برابر نگه‌داشتن همه‌چیز). هر فلش یک سوال می‌پرسد و هر جواب قیمتش را می‌گوید — همین «به چه قیمتی» جواب مصاحبه‌ای توست.

The hub states the chapter thesis: no solutions, only trade-offs. The three upper edges are the data world: OLTP vs OLAP (where data is created vs analyzed), record vs derived (where truth lives and how copies keep up), and warehouse vs lake (analysis over a curated copy or raw files).

The three lower edges are architecture decisions: cloud vs self-hosting (build or buy), single-machine vs distributed (single-node first, distribute only with a named reason), and data vs law (the right to be forgotten and minimization vs keeping everything). Each arrow asks a question and each answer names its price — that “at what price” is your interview answer.

۶6 بسته مصاحبهInterview pack

۶.۱ همه‌چیز در یک نگاه6.1 Everything at a glance

اصطلاحتعریف یک‌خطیکلیدواژه مصاحبه
Data-Intensiveچالش اصلی، مدیریت داده است نه محاسبهحجم، تغییر، سازگاری، دسترس‌پذیری
OLTPخواندن/نوشتن تک‌رکورد تعاملیpoint query، وضعیت فعلی
OLAPتجمیع روی اسکن‌های عظیمad-hoc، تاریخچه، TB→PB
Data Warehouseکپی فقط‌خواندنی برای BIETL، اسکیمای تحلیلی
Data Lakeفایل‌های خام بدون اسکیمای اجباریAvro/Parquet، raw is better
ETL / ELTترتیب تبدیل و بارگذاریtransform کجا انجام شود
HTAPOLTP+OLAP زیر یک رابطدو موتور پنهان داخلی
Reverse ETLبازگرداندن خروجی تحلیل به عملیاتمدل ML در پروداکشن
System of Recordنسخه مرجع و اولین جای نوشتنsource of truth
Derived Dataقابل بازسازی از مرجعcache، index، MV
CDCانتشار جریان تغییرات رکوردهابه‌روزرسانی داده مشتق‌شده
Cloud Nativeطراحی بر پایه سرویس‌های ابریobject storage، multitenancy
Disaggregationجدایی ذخیره‌سازی از محاسبهدیسک محلی = کش موقت
Microservicesراه‌حل فنی برای استقلال تیم‌هاپایگاه داده جدا، تکامل API
Serverless / FaaSپرداخت به‌ازای اجراcold start، محدودیت زمان
Idempotencyتکرار امن یک عملیاتپاسخ به retry در شبکه
TermOne-line definitionInterview keyword
Data-IntensiveThe core challenge is data, not computationVolume, change, consistency, availability
OLTPInteractive single-record reads/writesPoint query, current state
OLAPAggregation over giant scansAd-hoc, history, TB→PB
Data WarehouseRead-only copy for BIETL, analytical schema
Data LakeRaw files, no enforced schemaAvro/Parquet, raw is better
ETL / ELTOrder of transform and loadWhere transform happens
HTAPOLTP+OLAP under one interfaceTwo hidden engines inside
Reverse ETLReturning analytical output to operationsML model in production
System of RecordReference version, first place of writeSource of truth
Derived DataRebuildable from the recordCache, index, MV
CDCStreaming record changes outUpdating derived data
Cloud NativeDesigned on cloud servicesObject storage, multitenancy
DisaggregationStorage separated from computeLocal disk = temp cache
MicroservicesTechnical fix for team independenceSeparate DBs, API evolution
Serverless / FaaSPay per executionCold start, time limits
IdempotencySafe repetition of an operationAnswer to network retry

۶.۲ هفده سوال پرتکرار (برای دیدن جواب کلیک کن)6.2 Seventeen frequent questions (click for answers)

۱. سیستم data-intensive یعنی چه؟ فرقش با compute-intensive؟1. What is a data-intensive system? How does it differ from compute-intensive?

در سیستمِ داده‌محور، مسئلهٔ اصلی نگهداری، پیدا کردن و هماهنگ ماندن اطلاعات است. در سیستمِ محاسبه‌محور، اجرای محاسبهٔ سنگین مسئلهٔ اصلی است.

مثال فنی: دادهٔ بیشتر یا محاسبهٔ بیشتر؟

وضعیت اولیه: سرویس سفارش روزانه یک میلیون رکورد با customer_id و status نگه می‌دارد.

اجرای مرحله‌به‌مرحله: پرس‌وجوی وضعیت باید رکورد درست را با ایندکس پیدا کند؛ سرویس تبدیل ویدیو روی یک فایل، کدک را با CPU اجرا می‌کند.

نتیجه و دلیل: اولی بیشتر با نگهداری و بازیابی داده درگیر است؛ دومی بیشتر با هزینهٔ محاسبه. یک محصول می‌تواند هر دو نوع بار را داشته باشد.

Data-intensive means the core challenge is data: high volume, constant change, coping with failure/concurrency, high availability. Compute-intensive means the challenge is parallelizing one giant computation.

۲. پنج تفاوت OLTP و OLAP را بگو.2. Name five OLTP vs OLAP differences.

پنج تفاوتِ اصلی: خواندنِ چند رکورد در برابر اسکنِ انبوه؛ تغییرِ کوچک در برابر ورودِ دسته‌ای؛ کاربرِ محصول در برابر تحلیلگر؛ پرس‌وجوی مشخص در برابر اکتشافی؛ و وضعیتِ فعلی در برابر تاریخچه.

مثال فنی: دو پرس‌وجو، دو الگوی دسترسی

وضعیت اولیه: جدول orders صد میلیون ردیف دارد و روی id ایندکس شده است.

اجرای مرحله‌به‌مرحله: WHERE id=42 با ایندکس چند صفحه را می‌خواند؛ SUM(amount) برای کل سال حجم زیادی از ستون مبلغ را اسکن می‌کند.

نتیجه و دلیل: اولی نمونهٔ OLTP و دومی OLAP است؛ ایندکس مناسب اولی لزوماً گزارش دوم را سریع نمی‌کند.

Read pattern (point query vs scan+aggregate), write pattern (single-record vs bulk/stream), query type (fixed vs ad-hoc), data meaning (current state vs history), size (GB–TB vs TB–PB). Audience differs too: end user vs analyst.

۳. Data Warehouse و Data Lake چه فرقی دارند؟3. Warehouse vs lake?

انبار داده معمولاً اطلاعاتِ ساخت‌یافته و آمادهٔ تحلیل دارد. دریاچهٔ داده قالب‌های متنوع، از جمله فایل خام، نگه می‌دارد؛ هر دو به مدیریتِ کیفیت و معنای داده نیاز دارند.

مثال فنی: یک ورودی، فایل خام و جدول آماده

وضعیت اولیه: فایل JSON فروش مبلغ را در دو واحد متفاوت دارد و تصویر کالا هم کنار آن نگهداری می‌شود.

اجرای مرحله‌به‌مرحله: دریاچه فایل‌های خام و قالب‌های مختلف را نگه می‌دارد؛ pipeline واحد مبلغ را یکسان و جدولِ fact فروش را برای انبار آماده می‌کند.

نتیجه و دلیل: query انبار روی قرارداد آمادهٔ fact اجرا می‌شود؛ خواندن خام در lake همچنان به تشخیص schema و کیفیت داده نیاز دارد.

Warehouse = relational database with a curated schema and SQL for BI; lake = raw schema-less files for data scientists — cheaper and more flexible.

۴. ETL در برابر ELT؟4. ETL vs ELT?

در ETL، داده پیش از ورود به مقصد تبدیل می‌شود. در ELT، ابتدا وارد مقصد می‌شود و تبدیل در آنجا انجام می‌گیرد.

مثال فنی: ETL و ELT روی واحد مبلغ

وضعیت اولیه: منبع اول مبلغ 100 تومان و منبع دوم 1000 ریال می‌فرستد.

اجرای مرحله‌به‌مرحله: در ETL هر دو پیش از بارگذاری به 1000 ریال تبدیل می‌شوند؛ در ELT دادهٔ خام ابتدا بارگذاری و تبدیل در مقصد اجرا می‌شود.

نتیجه و دلیل: خروجی نهایی می‌تواند یکسان باشد؛ تفاوت در محل و زمان تبدیل و منابع مصرفی آن است.

ETL: transform in the pipeline, then load. ELT: load first, transform at the destination. It depends on where you have compute power and schema control.

۵. چرا تحلیل را روی پایگاه داده عملیاتی اجرا نمی‌کنیم؟5. Why not run analytics on the operational DB?

تحلیل ممکن است به دادهٔ چند سیستم نیاز داشته باشد، با ساختارِ عملیاتی راحت نباشد، منابعِ زیادی مصرف کند یا دسترسیِ جدا بخواهد. جداسازی بر اساسِ همین نیازهاست، نه ممنوعیتِ همیشگیِ تحلیل روی مرجع.

مثال فنی: ثبت خرید در برابر گزارش فروش

وضعیت اولیه: ثبت سفارش فقط ردیف سفارش 42 و موجودی کالای P7 را تغییر می‌دهد.

اجرای مرحله‌به‌مرحله: گزارش ماهانه SUM(amount) GROUP BY city باید میلیون‌ها ردیف را بخواند. اجرای هم‌زمان هر دو روی منابع محدود صف ایجاد می‌کند.

نتیجه و دلیل: نسخهٔ تحلیلی رقابت منابع را کم می‌کند، ولی گزارش به‌اندازهٔ تأخیر انتقال از مرجع عقب می‌ماند.

Data silos across systems, OLTP schemas unfit for analysis, heavy queries starving users, and security limits on direct access.

۶. System of Record و Derived Data را تعریف و مثال بزن.6. Define system of record and derived data, with examples.

سیستمِ مرجع نسخهٔ معتبرِ هر داده را نگه می‌دارد. دادهٔ مشتق‌شده با تبدیلِ مرجع ساخته می‌شود و باید مسیرِ ساخت و به‌روزرسانیِ مشخص داشته باشد.

مثال فنی: بازسازی دادهٔ مشتق‌شده

وضعیت اولیه: مرجع کالا P7 را با version=12 نگه داشته؛ ایندکس جست‌وجو خراب شده است.

اجرای مرحله‌به‌مرحله: snapshot مرجع تا موقعیت لاگ 500 وارد ایندکس تازه می‌شود و سپس تغییرهای پس از 500 اعمال می‌شوند.

نتیجه و دلیل: با مرز snapshot و لاگِ هماهنگ می‌توان ایندکس را بازسازی کرد؛ صرفِ کپی قدیمی ممکن است تغییرهای حین کپی را جا بیندازد.

Record: the first, most authoritative version of data; each fact once; it wins disagreements. Derived: transformed from existing data (cache, index, MV, ML model), rebuildable from the record.

۷. چرا کش و ایندکس «مشتق‌شده»‌اند و این چه فایده‌ای دارد؟7. Why are caches and indexes “derived”, and why does it matter?

کش و ایندکس، داده را برای خواندنِ خاصی آماده می‌کنند. اگر فقط از مرجع ساخته شده باشند و ورودیِ لازم موجود باشد، خرابیِ آن‌ها با بازسازی جبران می‌شود.

مثال فنی: بازسازی دادهٔ مشتق‌شده

وضعیت اولیه: مرجع کالا P7 را با version=12 نگه داشته؛ ایندکس جست‌وجو خراب شده است.

اجرای مرحله‌به‌مرحله: snapshot مرجع تا موقعیت لاگ 500 وارد ایندکس تازه می‌شود و سپس تغییرهای پس از 500 اعمال می‌شوند.

نتیجه و دلیل: با مرز snapshot و لاگِ هماهنگ می‌توان ایندکس را بازسازی کرد؛ صرفِ کپی قدیمی ممکن است تغییرهای حین کپی را جا بیندازد.

Because they are built from record data and rebuildable if dropped. Once the “what derives from what” map is explicit, you know everywhere each change must propagate.

۸. HTAP چیست و چرا جایگزین انبارداده نشد؟8. What is HTAP, and why didn’t it replace the warehouse?

HTAP بارِ تراکنشی و تحلیلی را نزدیک‌تر می‌کند، اما نیازِ جمع کردنِ دادهٔ چند منبع، تاریخچه و ساختارِ مناسبِ تحلیل را خودبه‌خود حذف نمی‌کند.

مثال فنی: HTAP و نیاز چندمنبعی

وضعیت اولیه: یک موتور هم ثبت سفارش و هم گزارش سریع روی همان سفارش‌ها را پشتیبانی می‌کند.

اجرای مرحله‌به‌مرحله: گزارش نرخ تبدیل، کلیک وب و تماس پشتیبانی را هم لازم دارد؛ این داده‌ها هنوز باید با customer_id و بازهٔ زمانی یکپارچه شوند.

نتیجه و دلیل: نزدیک شدن OLTP و OLAP نیاز به هماهنگ کردن دادهٔ چند سامانه را حذف نمی‌کند.

HTAP aims to serve transactional and analytical load in one system, but it is usually two engines inside and doesn’t remove the need for “one combined copy of all systems”.

۹. Reverse ETL چیست؟9. What is reverse ETL?

Reverse ETL یعنی نتیجهٔ آمادهٔ تحلیل را به ابزارِ عملیاتی برگردانیم تا در کارِ روزمره استفاده شود.

مثال فنی: برگرداندن نتیجهٔ تحلیل به عملیات

وضعیت اولیه: انبار داده برای مشتری 17 مجموع خرید ۹۰ روزه را 8000 محاسبه کرده است.

اجرای مرحله‌به‌مرحله: job مشتریان با مجموع بالای 5000 را با کلید customer_id به CRM منتقل می‌کند و زمان محاسبه را هم می‌فرستد.

نتیجه و دلیل: CRM از برچسب آماده استفاده می‌کند؛ این Reverse ETL است. برچسب تا اجرای بعدی به‌روز نمی‌شود.

Sending analytical output back to operational systems — e.g. a trained model for recommendations, or a churn-risk list returning to the CRM.

۱۰. Cloud Native یعنی چه؟ جدایی storage و compute چه فایده‌ای دارد؟10. What is cloud native? What does storage/compute separation buy you?

طراحیِ ابری از قابلیت‌های محیطِ ابر استفاده می‌کند. با جداییِ ذخیره و محاسبه، می‌توان ظرفیتِ پردازش را مستقل از داده تغییر داد؛ صرفِ اجرا روی ماشینِ ابری کافی نیست.

مثال فنی: پردازش جدا از فایل‌ها

وضعیت اولیه: گزارش روی 10 TB فایل فروش در مخزن مشترک اجرا می‌شود.

اجرای مرحله‌به‌مرحله: برای گزارش آخر ماه ۲۰ worker فایل‌ها را تقسیم می‌کنند؛ پس از پایان خاموش می‌شوند و فایل‌ها باقی می‌مانند.

نتیجه و دلیل: ظرفیت compute مستقل از حجم داده تغییر می‌کند؛ توان خواندن مخزن و انتقال شبکه هنوز می‌تواند گلوگاه باشد.

Designed from the ground up on cloud services instead of “legacy software on a VM”. Separation lets compute scale independently of data, and machines be replaced without data loss.

۱۱. دیسکِ محلیِ موقت و EBS چه تفاوتی دارند؟11. Why is the cloud local disk ephemeral, and what is the EBS trap?

دیسکِ محلیِ موقت با دیسکِ پایدارِ ابری فرق دارد. در EC2، instance store برای دادهٔ موقت است؛ EBS ذخیرهٔ بلوکیِ متصل از شبکه است و رفتار و هزینه‌اش باید جدا سنجیده شود.

مثال فنی: دیسک موقت در برابر EBS

وضعیت اولیه: worker ابری فایل میانی قابل‌بازسازی و تنها نسخهٔ سفارش تأییدشده را تولید می‌کند.

اجرای مرحله‌به‌مرحله: فایل میانی را می‌توان روی instance store گذاشت؛ برای دادهٔ معتبر، ذخیرهٔ پایدار و سیاست backup لازم است. EBS مستقل از دیسک محلی است و حذف هنگام پایان نمونه به تنظیمات بستگی دارد.

نتیجه و دلیل: نوع دیسک و چرخهٔ عمرش بخشی از طراحی ماندگاری است؛ «روی ابر است» پاسخ کافی نیست.

منبعِ توضیحِ فنی: ذخیرهٔ موقتِ EC2 · ذخیرهٔ بلوکیِ EBS

It goes away with failure or resizing — so it is only a cache. EBS emulates a disk over the network, turning every I/O into a network call → sensitive to network variance.

۱۲. Multitenancy چه سود و چه ریسکی دارد؟12. Multitenancy: benefit and risk?

چندمستاجری منابع و عملیات را مشترک می‌کند و می‌تواند هزینه را کم کند. در مقابل، جداسازیِ دسترسی و جلوگیری از اثرِ بارِ یک مشتری بر بقیه ضروری است.

مثال فنی: همسایهٔ پرمصرف

وضعیت اولیه: دو tenant از یک پایگاه داده استفاده می‌کنند؛ tenant A گزارشِ اسکن کامل می‌فرستد.

اجرای مرحله‌به‌مرحله: سهم منابع و محدودیت هم‌زمانی برای A گذاشته می‌شود و همهٔ پرس‌وجوها با tenant_id محدود می‌شوند.

نتیجه و دلیل: کنترل بار از کند شدن B جلوگیری می‌کند؛ کنترل دسترسی مسئلهٔ جداگانهٔ نشت داده بین tenantها را پوشش می‌دهد.

Benefit: hardware efficiency and easier management. Risk: one tenant must not harm others’ performance or security; it demands precise isolation.

۱۳. کی باید سراغ سیستم توزیع‌شده برویم؟13. When should we go distributed?

وقتی مسئله‌ای واقعی مثل ظرفیتِ ناکافی، خرابی، تأخیرِ جغرافیایی، کشسانی، نیازِ سخت‌افزاری یا محدودیتِ محلِ داده داریم، توزیع را بررسی می‌کنیم. باید کمترین توزیعِ لازم را انتخاب کرد.

مثال فنی: توزیع برای حل یک محدودیت مشخص

وضعیت اولیه: آرشیو 40 TB است و هر سرور فقط 10 TB فضای قابل‌استفاده دارد.

اجرای مرحله‌به‌مرحله: کلیدها بین چند shard تقسیم می‌شوند و برای هر shard نسخهٔ پشتیبانِ زنده در نظر گرفته می‌شود.

نتیجه و دلیل: sharding ظرفیت را زیاد می‌کند و replication تحمل خرابی را؛ این دو وظیفه را نباید با هم اشتباه گرفت.

When one of these is real: inherent user distribution, fault tolerance, beyond-one-machine scale, geo latency, elasticity, specialized hardware, data-residency law or sustainability. Name the reason first, then pick minimal distribution.

۱۴. هزینه‌های پنهان سیستم توزیع‌شده چیست؟14. Hidden costs of distribution?

شبکه تأخیر و نتیجهٔ نامشخص می‌آورد؛ بازتلاش، اشکال‌زدایی و نگه داشتنِ دادهٔ سازگار میان سرویس‌ها هم سخت‌تر می‌شود.

مثال فنی: ثبت موفق، پاسخ گم‌شده

وضعیت اولیه: سرویس سفارش درخواست r7 را ثبت می‌کند، اما پاسخ در شبکه گم می‌شود.

اجرای مرحله‌به‌مرحله: کلاینت همان r7 را دوباره می‌فرستد؛ قید یکتایی روی شناسهٔ درخواست اجازهٔ سفارش دوم نمی‌دهد و نتیجهٔ قبلی برمی‌گردد.

نتیجه و دلیل: timeout شکست قطعی عملیات نیست؛ تولید شناسهٔ تازه در هر retry می‌تواند دو سفارش واقعی بسازد.

Timeouts and request-status ambiguity, unsafe-retry risk, network slower than local calls, hard debugging, and cross-service consistency becoming the application’s job.

۱۵. چرا retry کورکورانه خطرناک است؟15. Why is blind retry dangerous?

پس از timeout نمی‌دانیم عملیات اجرا شده یا نه. شناسهٔ ثابت و عملیاتِ مقاوم به تکرار یا استعلامِ نتیجه، جلوی اثرِ دوباره را می‌گیرند.

مثال فنی: ثبت موفق، پاسخ گم‌شده

وضعیت اولیه: سرویس سفارش درخواست r7 را ثبت می‌کند، اما پاسخ در شبکه گم می‌شود.

اجرای مرحله‌به‌مرحله: کلاینت همان r7 را دوباره می‌فرستد؛ قید یکتایی روی شناسهٔ درخواست اجازهٔ سفارش دوم نمی‌دهد و نتیجهٔ قبلی برمی‌گردد.

نتیجه و دلیل: timeout شکست قطعی عملیات نیست؛ تولید شناسهٔ تازه در هر retry می‌تواند دو سفارش واقعی بسازد.

On timeout you don’t know whether the operation happened; retrying may apply the effect twice (e.g. double charge). Fix: idempotent keys and operations.

۱۶. چرا میکروسرویس برای تیم کوچک overkill است؟16. Why are microservices overkill for a small team?

میکروسرویس می‌تواند استقلالِ تیم‌ها را بیشتر کند، ولی استقرار، آزمون، پایش و قراردادِ شبکه هزینه دارند. برای تیمِ کوچک، این هزینه ممکن است از سودِ جداسازی بیشتر باشد.

مثال فنی: هزینهٔ خرد کردن برنامه

وضعیت اولیه: سه نفر روی یک برنامهٔ ماژولار کار می‌کنند و یک مسیر انتشار دارند.

اجرای مرحله‌به‌مرحله: تقسیم آن به ۱۰ سرویس، قرارداد شبکه، مانیتورینگ، timeout و انتشار جدا برای هر سرویس می‌خواهد.

نتیجه و دلیل: جداسازی وقتی مفید است که استقلال یا مقیاس لازم را بدهد؛ تعداد بیشتر سرویس به‌تنهایی پیشرفت معماری نیست.

Microservices solve the human problem of “team independence”; in a small team their cost (testing, deploys, monitoring, API evolution) exceeds the benefit.

۱۷. «حق فراموش شدن» با لاگ‌های append-only چه تضادی دارد؟17. How does the right to be forgotten clash with append-only logs?

لاگِ فقط‌افزودنی برای حفظِ تاریخچه طراحی شده، اما حذفِ داده باید در مرجع، نسخه‌های مشتق‌شده و سیاستِ نگهداری دیده شود. جزئیاتِ الزامِ حقوقی به مورد بستگی دارد.

مثال فنی: حذف در چند نسخه

وضعیت اولیه: دادهٔ مشتری 17 در مرجع، ایندکس و فایل خروجی گزارش کپی شده است.

اجرای مرحله‌به‌مرحله: جریان حذف با همین شناسه مقصدها را دنبال می‌کند؛ وضعیت حذف، زمان نگهداری و محدودیت backup نیز ثبت می‌شوند.

نتیجه و دلیل: حذف یک ردیف به‌معنی حذف همهٔ کپی‌ها نیست؛ دامنه و الزام نگهداری باید برای همین کاربرد بررسی شود.

Many systems are built on immutable structures; deleting from their middle — and from derived data like model training sets — is a fresh engineering challenge. And data minimization says some data should never be kept at all.

۶.۳ اشتباهات رایج در جواب‌های مصاحبه6.3 Common interview mistakes

  • گفتن «میکروسرویس بهتر است» بدون نام بردن دلیل و هزینه‌اش.
  • استفاده از کش/ایندکس به‌عنوان منبع حقیقت، یا نداشتن مکانیزم انتشار تغییر.
  • نفهمیدن فرق «کپی فقط‌خواندنی تحلیلی» و «پایگاه داده عملیاتی».
  • فراموش کردن اینکه در سیستم توزیع‌شده، timeout یعنی «نمی‌دانیم» نه «انجام نشد».
  • تحلیل نکردن تریدآف: هر جواب باید بگوید «به چه قیمتی».
  • Saying “microservices are better” without naming a reason and a cost.
  • Treating cache/index as the source of truth, or having no change-propagation mechanism.
  • Missing the difference between a “read-only analytical copy” and the “operational database”.
  • Forgetting that in distributed systems, timeout means “unknown”, not “failed”.
  • Skipping the trade-off: every answer must say “at what price”.

۶.۴ چک‌لیست مرور ۵ دقیقه‌ای6.4 Five-minute checklist

  1. جدول OLTP/OLAP را از حفظ بگو (۵ سطر).
  2. تعریف record/derived + مثال‌هایش.
  3. مسیر داده: operational ← ETL ← warehouse/lake ← consumer ← reverse ETL.
  4. سه مزیت و سه ریسک کلاود + یک جمله درباره جدایی storage/compute.
  5. سه دلیل توزیع + سه هزینه‌اش + کلمه idempotency.
  6. یک جمله درباره GDPR و data minimization.
  1. Recite the OLTP/OLAP table from memory (5 rows).
  2. The record/derived definition + examples.
  3. The data path: operational → ETL → warehouse/lake → consumer → reverse ETL.
  4. Three cloud benefits and three risks + one sentence on storage/compute separation.
  5. Three reasons to distribute + three costs + the word idempotency.
  6. One sentence on GDPR and data minimization.

۷7 تمرین‌های مصاحبه و آزمایشگاهInterview exercises and hands-on labs

این تمرین‌ها برای مسیر Backend / Distributed Systems در ۱۴ اکتبر ۲۰۲۶ بازبینی شدند. سطح مربوط به نسخهٔ مصاحبه‌ای است؛ زمان آزمایشگاه جداست.Reviewed on 14 October 2026 for Backend / Distributed Systems. Level refers to the interview brief; full-lab time is separate. روش ارزیابی و مسیر مطالعهMethod and study path

تمرین ۱ — معماری یک فروشگاه آنلاینExercise 1 — an online shop’s architecture

L2 · SeniorL2 · Seniorاولویت اصلیCore priority35 دقیقه بحث35 min discussion

مرجع داده، مشتق‌ها و انتشار تغییر، مسئلهٔ واقعی طراحی است؛ صرف نام‌گذاری اجزا عمق کافی ندارد.Record and derived data are useful, but classification alone is too shallow.

نسخهٔ بازبینی‌شده برای مصاحبهReviewed interview brief

فروشگاهی را طراحی کن که سفارش را ثبت می‌کند و کش، جست‌وجو، گزارش و پیشنهاد محصول دارد. مرجع هر واقعیت را مشخص کن. اگر سفارش commit شود ولی انتشار رویداد شکست بخورد چه می‌کنی؟ قرارداد تازگی هر نما، مسیر بازسازی و هزینهٔ حداقل معماری را توضیح بده.Design order storage and its cache, search, reporting and recommendation views. Explain commit-without-publication, freshness contracts, rebuilding and minimum cost.

معیار پاسخ خوبWhat a good answer demonstrates

  • مرجع و مشتق را برای هر واقعیت جدا می‌کندAuthority per fact
  • dual write، outbox/CDC و idempotency را تحلیل می‌کندAtomic publication and idempotence
  • برای تازگی و بازسازی معیار قابل سنجش داردFreshness and rebuild criteria

پیگیری مصاحبه:Interview follow-up: اگر مشتری بلافاصله بعد از ثبت سفارش آن را در جست‌وجو نبیند، تجربهٔ کاربر را چطور حفظ می‌کنی؟How do you preserve the user experience if a new order is not yet visible in search?

آزمایشگاه تکمیلی · زمان تقریبی ۳۰–۶۰ دقیقهExtended hands-on laboratory · estimated 30–60 minutes

برای این اجزا مشخص کن هرکدام system of record است یا derived و چرا: پایگاه داده سفارش‌ها، کش وضعیت سفارش، ایندکس جست‌وجوی سفارش‌ها، گزارش ماهانه فروش، مدل پیشنهاد محصول. بعد بگو: با ثبت سفارش جدید، کدام سیستم‌ها باید به‌روز شوند و مکانیزم انتشار چه باشد؟

For each of these, decide system of record or derived and why: the orders database, the order-status cache, the order search index, the monthly sales report, the recommendation model. Then: when a new order lands, which systems must update, and by what propagation mechanism?

برای یادگیریِ عمیق است؛ انجام کاملش در زمان بحثِ مصاحبه انتظار نمی‌رود.The full laboratory is optional depth work and is not expected within the discussion time.

ارزیابی، سطح و شواهد این تمرینAssessment, level and evidence · حل آموزشی این تمرینWorked solution · Amazon · SDE III interview preparation · Debezium · outbox event router

تمرین ۲ — تصمیم توزیعExercise 2 — the distribution decision

L2 · SeniorL2 · Seniorاولویت اصلیCore priority40 دقیقه بحث40 min discussion

برآورد بار و انتخاب کمترین توزیع مفید است؛ تعداد سفارش روزانه به‌تنهایی دلیل sharding نیست.Capacity estimates should justify distribution rather than assume it.

نسخهٔ بازبینی‌شده برای مصاحبهReviewed interview brief

روزانه دو میلیون سفارش، اوج ده‌برابری، گزارش فروش و الزام نگهداری داده در یک کشور داریم. ابتدا اندازهٔ رکورد، read/write ratio، SLO و رشد را روشن کن. سه طرح تک‌گره، primary+replica و sharding را با شواهد ظرفیت مقایسه کن؛ بکاپ، failover و محل داده را هم پوشش بده.Compare single-node, primary/replica and sharded designs for two million daily orders, tenfold peaks, analytics and in-country storage. Specify workload, SLOs, growth, failover, backup and migration thresholds.

معیار پاسخ خوبWhat a good answer demonstrates

  • میانگین را با peak اشتباه نمی‌گیردAverage versus peak
  • residency را با لزوم sharding یکی نمی‌گیردResidency versus sharding
  • threshold مهاجرت و هزینهٔ عملیاتی را مشخص می‌کندMigration thresholds and cost

پیگیری مصاحبه:Interview follow-up: با پنج برابر شدن حجم و نصف شدن بودجه، کدام بخش را اول تغییر می‌دهی؟With fivefold data growth and half the budget, which component do you change first?

آزمایشگاه تکمیلی · زمان تقریبی ۳۰–۶۰ دقیقهExtended hands-on laboratory · estimated 30–60 minutes

سناریو: روزانه ۲ میلیون سفارش، گزارش‌های تحلیلی تیم فروش، و قانونی که داده کاربران باید داخل کشور بماند. برای هر سه بگو چه زمانی از «تک‌ماشین» به «توزیع‌شده» می‌رسی، دلیل دقیق چیست و حداقل معماری انتخابی چه شکلی است.

Scenario: 2M orders/day, analytical reports for the sales team, and a law keeping user data inside the country. For each, say when you move from “single-node” to “distributed”, the exact reason, and what the minimal chosen architecture looks like.

برای یادگیریِ عمیق است؛ انجام کاملش در زمان بحثِ مصاحبه انتظار نمی‌رود.The full laboratory is optional depth work and is not expected within the discussion time.

ارزیابی، سطح و شواهد این تمرینAssessment, level and evidence · حل آموزشی این تمرینWorked solution · Amazon · SDE III interview preparation · Atlassian · engineering interview handbook

تمرین ۳ — چالش GDPRExercise 3 — the GDPR challenge

L3 · Staff / PrincipalL3 · Staff / Principalوابسته به نقشRole-specific35 دقیقه بحث35 min discussion

حذف داده در سامانه‌های لاگ‌محور برای پلتفرم و حریم خصوصی مهم است؛ انتظار حفظ متن قانون برای همهٔ نقش‌ها مناسب نیست.Important for privacy/platform roles; legal memorization is not a general backend requirement.

نسخهٔ بازبینی‌شده برای مصاحبهReviewed interview brief

درخواست حذف یک کاربر را از مرجع تا کش، ایندکس، لاگ، بکاپ و مجموعهٔ آموزش دنبال کن. گزینه‌های جداسازی PII، retention، بازنویسی سگمنت و حذف کلید رمز را مقایسه کن. بگو چه چیزی در restore نباید دوباره زنده شود و کدام تصمیم نیازمند تفسیر حقوقی است.Trace deletion through the record, cache, index, log, backup and training data. Compare PII separation, retention, rewriting and key deletion. Prevent resurrection after restore and identify legal uncertainties.

معیار پاسخ خوبWhat a good answer demonstrates

  • همهٔ کپی‌ها و restore را پوشش می‌دهدDerived copies and restore
  • محدودیت crypto-shredding و لینک‌پذیری را می‌بیندKey-deletion limitations
  • تأیید حذف را با مدرک و SLA داخلی طراحی می‌کندDeletion evidence and deadlines

پیگیری مصاحبه:Interview follow-up: اگر یک مصرف‌کنندهٔ قدیمی هنگام حذف آفلاین باشد چه تضمینی داری؟What happens when an old consumer is offline throughout a deletion?

آزمایشگاه تکمیلی · زمان تقریبی ۱–۲ ساعتExtended hands-on laboratory · estimated 1–2 hours

اگر سیستمت روی append-only event log ساخته شده و کاربر حذف داده‌اش را بخواهد، چه گزینه‌های مهندسی داری؟ هر گزینه را با تریدآفش بیان کن.

If your system is built on an append-only event log and a user requests deletion, what engineering options do you have? State each option with its trade-off.

برای یادگیریِ عمیق است؛ انجام کاملش در زمان بحثِ مصاحبه انتظار نمی‌رود.The full laboratory is optional depth work and is not expected within the discussion time.

ارزیابی، سطح و شواهد این تمرینAssessment, level and evidence · حل آموزشی این تمرینWorked solution · European Commission · GDPR principles · Atlassian · engineering interview handbook

→ بازگشت به نقشه راه→ Back to the roadmap فصل ۲: نیازمندی‌های غیرعملکردی ←Chapter 2: Nonfunctional requirements →