System Design

#إطار إجابة System DesignA framework for system design answers

السؤال المفتوح بيختبر اختيارك للـ trade-offs. قبل أي رسمة، اتفق على المطلوب والحدود. مثال المتجر: هل المطلوب catalog ولا checkout؟ هل بنصمم لبلد واحدة؟ وهل الدفع confirmed فورًا ولا الطلب ممكن يفضل pending؟

1. حدّد functional requirements، وnon-goals، والمستخدمين.
2. اسأل عن peak load، وحجم الداتا، وlatency SLO، وavailability، وRPO وRTO.
3. قدّر الأرقام واكتب الافتراضات.
4. عرّف APIs والـ data model والـ invariants.
5. ارسم أبسط مسار شغّال، وبعدها تعمّق في أصعب حتة: consistency أو fan-out أو security.
6. اختبر الرسمة بعطل وtraffic spike، واشرح القياس والتوسعة والتكلفة.

RPO مقدار فقد الداتا المقبول، وRTO زمن استعادة الخدمة المستهدف. ماتختارشهم من غير business context. في مقابلة 45 دقيقة، ممكن تخصص تقريبًا 5 للتوضيح، و5 للأرقام، و10 للرسمة، و20 للتعمق، و5 للأسئلة؛ عدّل حسب المحاور.

#حسابات تقريبية وlatency budgetsBack-of-envelope estimates and latency budgets

الأرقام تمنع إضافة infrastructure من غير سبب. خلّي units واضحة، وفرّق بين المتوسط والـ peak وبين request وbusiness operation. الأرقام الجاية افتراضات تدريبية للتقدير، مش benchmarks أو وعود أداء.

50,000 orders/day / 86,400 seconds/day ~= 0.58 orders/second average
Assume peak = 10 * average ~= 5.8 orders/second
At 8 API calls/order: ~= 46 order-related requests/second at peak
At 2 KB/order: ~= 100 MB/day raw, before lines, indexes, replicas and backups
1 million catalog reads/day ~= 11.6 reads/second average
At 200 requests/second and 0.15 seconds average response time:
Little's law: average in-flight requests ~= 200 * 0.15 = 30
Use a stable system boundary; queue wait belongs in response time.

قِس p50 وp95 وp99 في البيئة الحقيقية. latency الكلي مش جمع الـ p99 لكل service حسابيًا؛ ارسم المسار، وحدد المتوازي والمتتابع، وقِس end-to-end. الأرقام الصغيرة مش ضمان إن monolith هيكفي: لازم load test والـ query shape يتراجعوا.

#Building blocks: كل صندوق ليه تكلفةBuilding blocks: each box has a cost

Stateless API يعني مفيش session correctness معتمدة على memory instance بعينها؛ مش معناه مفيش state في النظام. قاعدة البيانات والـ queue والـ object storage لسه محتاجين إدارة وتعافي.

#تصميم 1: order processing لمتجرDesign 1: online-store order processing

افترض متجرًا في region واحدة، وطلبات قليلة نسبيًا، ومطلوب منع overselling وعدم تكرار الدفع. ابدأ modular monolith وrelational DB. الـ catalog ممكن يقبل staleness، لكن قرار حجز آخر قطعة لازم يتنفذ ذريًا.

Client -> LB -> Stateless .NET API -> DB: orders, reservations, idempotency, outbox
                       |                                      |
                       v                                      v
                Payment provider                   Outbox relay -> broker
                       |                                      |
             Verified webhook -> API                  Notifications / shipping
                       ^
              Reconciliation worker

POST /orders                  Idempotency-Key scoped to customer and operation
GET  /orders/{id}              Ownership check
POST /payments/webhooks        Verify signature, amount, currency and event ID

1. في transaction واحدة احجز المخزون، واحفظ Pending order والـ idempotency key وpayload hash والـ outbox. unique constraint تمنع طلبين بنفس المفتاح؛ نفس المفتاح مع payload مختلف يُرفض.
2. بعد commit، نفّذ الدفع خارج transaction الـ DB بمفتاح idempotency يدعمه الـ provider. timeout معناه unknown، مش declined.
3. Webhook متحقق منه يعمل state transition مشروط ويسجل event ID؛ duplicate callback مايعيدش side effect.
4. Reconciliation يسأل الـ provider عن المحاولات المعلقة. reservation expiry لازم تتنسق مع الدفع المتأخر: جدد الحجز أو اعمل refund حسب سياسة واضحة.
5. Outbox relay ممكن ينشر مرتين لو وقع بعد publish وقبل mark-sent. المستهلك idempotent، وordering لو مطلوب يبقى لكل order مش لكل النظام.

-- (1) Inside the transaction that also creates the order and reservation.
UPDATE Stock
SET Available = Available - @quantity
WHERE TenantId = @tenant AND Sku = @sku
  AND Available >= @quantity;
-- (2) Require exactly one affected row; otherwise roll back and report unavailable.

الدفع الخارجي مش جزء من ACID الـ DB. لو قسمت الملكية لخدمات، هتحتاج state machine وcompensation ومراقبة؛ مش مجرد نقل methods لـ HTTP.

#تصميم 2: URL shortenerDesign 2: URL shortener

المطلوب إنشاء link وredirect سريع، مع expiry وإمكانية تعطيل abuse. افترض القراءات أكتر من الكتابة. عرّف Links(Code PK, Destination, OwnerId, ExpiresAt, Disabled). اعمل validate لـ http وhttps، وطول الرابط، وصلاحية صاحب التعديل.

1. POST /links يولّد code عشوائي من Base62 بقدر كفاية من entropy، ويحاول insert مع unique constraint؛ لو collision يحصل يولّد تاني. sequence مع Base62 بديل أبسط لكنه قابل للتخمين.
2. GET /{code} يقرأ hot mapping من cache، وبعدها DB، ويتحقق من expiry والتعطيل. TTL مايتعداش وقت انتهاء الرابط.
3. استخدم 302 لو الوجهة قابلة للتغيير وعايز تتحكم في caching؛ 301 دائم وممكن العميل يحتفظ بيه. وضّح Cache-Control بدل افتراض إن status وحده كفاية.
4. click analytics تروح queue بحدود، والـ redirect مايتعطلش لو analytics وقعت.

7 Base62 characters: 62^7 = 3,521,614,606,208 possible codes
Large address space does not eliminate random collisions.
Redirect: client -> edge/cache -> API -> Links DB
                                      -> async click event

الرابط القصير مش access token. للملفات الخاصة اعمل authorization مستقل. لو بتعمل preview للرابط من السيرفر، احمِ fetcher من SSRF وredirects لعناوين داخلية. لتعطيل فوري لازم cache invalidation وسياسة edge واضحة.

#تصميم 3: notificationsDesign 3: notification delivery

المشكلة إن نفس event ممكن ييجي مرتين، والـ provider ممكن يقبل الرسالة ويرد timeout. استقبل event من outbox، واقرأ تفضيلات العميل والموافقة، واختار template ولغة، وسجّل notification ومهام القنوات قبل الإرسال.

OrderShipped -> preferences + templates -> delivery records
                                             |
                       Email queue / SMS queue / Push queue
                                             |
                    Rate-limited workers -> provider -> status callbacks
Unique logical delivery: (EventId, RecipientId, Channel)
States: Pending -> Sending -> Accepted -> Delivered / Failed / Unknown

فرّق Accepted من Delivered. retry مع backoff وjitter للأخطاء المؤقتة، وDLQ مع سبب وإعادة تشغيل مدروسة. لو الـ provider بيدعم idempotency استخدمه؛ local dedup لوحده مش بيضمن exactly-once بعد crash. failover لمزوّد تاني وقت unknown ممكن يبعت مرتين، فحدد سياسة تمنع الضرر. احترم unsubscribe وquiet hours، وخلي المرفقات الحساسة روابط قصيرة الصلاحية بدل نسخ الداتا للـ logs.

#تصميم 4: rate limiterDesign 4: rate limiter

حدد هل بتحمي الخدمة من concurrency ولا بتحاسب requests في فترة. Fixed window بسيط لكن بيسمح بburst عند الحد. Sliding window ينعّم الحدود، وtoken bucket يسمح بburst محدود مع معدل مستمر. concurrency limiter بيحدد in-flight requests؛ مش عدد requests في الدقيقة.

للـ API على كذا instance، in-memory limiter بيطبق حد لكل instance. لو محتاج quota عالمية استخدم gateway أو distributed state مع تحديث ذري. المفتاح يكون tenant ومستخدم وendpoint حسب الهدف؛ IP وحده يظلم مستخدمين ورا NAT.

Token bucket state per key: tokens, lastRefillTime
Atomically:
  tokens = min(capacity, tokens + elapsed * refillRate)
  if tokens >= requestCost: subtract cost and allow
  otherwise: reject with 429 and a meaningful Retry-After when available
Never split read/refill/decrement into independent distributed commands.

حدد fail-open ولا fail-closed لو مخزن العداد وقع: catalog ممكن يسمح بحد محلي احتياطي، لكن endpoint مكلف يحتاج حماية أشد. TTL وحدود عدد keys تمنع memory abuse. حدّد queue قصيرة أو رفض؛ انتظار بلا حد مش حماية.

#تصميم 5: file upload serviceDesign 5: file upload service

تمرير ملف كبير كله في memory الـ API بيستهلك bandwidth وRAM. افصل control plane اللي بيتحقق من المستخدم ويصدر إذن upload، عن data plane اللي بيرفع لـ object storage.

1. POST /uploads يتحقق من quota والملكية، وينشئ object key عشوائي وسجل Pending، ويرجع signed URL قصيرة العمر لعملية محددة.
2. العميل يرفع مباشرة، أو multipart/resumable upload للملفات الكبيرة. ماتدّيش storage credentials دائمة.
3. Callback أو POST /uploads/{id}/complete يبدأ تحقق server-side من وجود الملف وحجمه وchecksum ونوعه الحقيقي؛ كلام العميل مش دليل نجاح.
4. الملف يفضل quarantined لحد فحص malware وسياسة المحتوى. state transition idempotent لـ Ready أو Rejected.
5. Download يحتاج authorization ورابط قصير الصلاحية. cleanup دوري يشيل incomplete uploads وorphan objects.

Client -> API: authorize, reserve quota, issue upload permission
Client -> private object storage: upload bytes
Storage event -> queue -> scanner -> metadata DB: Ready / Rejected
Client -> API: authorize download -> expiring object URL

DB والـ storage مش transaction واحدة. استعمل state machine وreconciliation، وحدد version/object identity اللي اتفحصت علشان تمنع تبديل الملف بعد الفحص. راجع القيود اللي signed URL يقدر يفرضها فعلًا عند الـ provider، وافحص الباقي server-side.

#Multi-tenancy واختيار العزلMulti-tenancy and isolation choices

Tenant مش user؛ المؤسسة ممكن يكون فيها مستخدمين بصلاحيات مختلفة. استخرج الـ tenant من الهوية الموثوقة، وضمّه للـ indexes والـ unique constraints حسب معنى الداتا، والـ cache keys والـ jobs والـ rate limits. EF query filters تساعد، وRLS ممكن تضيف دفاع في الـ DB؛ راجع raw SQL ومسارات الإدارة واستعمال connection pool.

DB منفصلة على نفس السيرفر مش compute isolation كامل. حدد مستوى العزل المطلوب: بيانات ولا موارد ولا region ولا مفاتيح تشفير.

#تكبير .NET API والـ reliabilityScaling a .NET API and preserving reliability

1. قِس bottleneck بـ traces وload tests: CPU ولا DB ولا dependency ولا thread pool؟ حدد SLO قبل التغيير.
2. صلّح N+1 والـ indexes والـ pagination والـ async I/O. راقب connection pool وحدود الـ downstream.
3. cache للقراءات اللي تقبل staleness وCDN للملفات؛ اختبر cache outage وstampede.
4. شغّل stateless instances ورا LB، وانقل session state المطلوب لمخزن مناسب. اختبر readiness وgraceful shutdown.
5. queue للشغل القابل للتأجيل، وworkers بحدود concurrency؛ استخدم 202 ومعاه status resource لو العقد يسمح.
6. Read replicas مع سياسة lag، وبعدها sharding لو القياس يثبت الحاجة وحجم التعقيد مبرر.

Redundancy محتاجة فصل failure domains وfailover مُجرّب. Backups لازم restore drills. graceful degradation ممكن توقف recommendations وتفضل checkout؛ backpressure بيقلل استقبال الشغل لما المستهلك مش لاحق. راقب queue age مش العدد بس، وحط deadlines وretry budgets وcircuit breakers للـ dependencies.