NFR در System Design | Non Functional Requirements به زبان فارسی

خلاصه کاربردی

NFR Summary

NFRها معمولاً وقتی مهم می‌شوند که سیستم بزرگ شده، کاربر زیاد شده، Incident رخ داده یا کسب‌وکار دیگر تحمل کندی و قطعی ندارد. اگر از اول درباره‌شان شفاف نباشیم، بعداً با نسخه گران‌تر و دردناک‌ترشان برمی‌گردند. مثل قرض؛ فقط بهره‌اش بیشتر است.

برای Product

کمک می‌کند بفهمیم کدام Journey باید سریع، پایدار یا دقیق باشد.

برای Engineering

کمک می‌کند Architecture، Database، Cache، Queue، Deployment و Monitoring درست انتخاب شود.

برای Management

کمک می‌کند بین Cost، Speed، Quality و Risk تصمیم قابل دفاع بگیریم.

⚖️

قانون طلایی

هیچ سیستمی همزمان در همه NFRها بهترین نیست. باید بدانیم برای این محصول، در این مرحله، کدام کیفیت مهم‌تر است.

Performance

Speed for each request

Performance یعنی سیستم چقدر سریع و efficient به درخواست کاربر جواب می‌دهد. مسئله اصلی این است: کاربر بعد از کلیک کردن، چقدر منتظر می‌ماند؟

سوال Product Owner

کدام action باید حس instantaneous داشته باشد؟ مثلاً باز شدن صفحه اصلی، پرداخت، جستجو یا نمایش موجودی؟

Metrics مهم

Response Time
p95 / p99
Latency
TTFB

مثال: در یک اپلیکیشن فروشگاهی، صفحه Product باید زیر ۲ ثانیه باز شود؛ اما Export گرفتن از گزارش فروش می‌تواند ۳۰ ثانیه طول بکشد و Async انجام شود. هر دو Feature هستند، ولی Performance requirement یکسان ندارند.

Patterns

Connection Pooling
Indexing
Parallel Processing
Asynchronous Processing
Caching / CDN

Anti-patterns

Premature Optimization
Blocking I/O
Chatty APIs
N+1 Queries
Retry Storm

Scalability

Handle growth

Scalability یعنی سیستم بتواند با رشد User، Data یا Transaction کنار بیاید؛ معمولاً با اضافه کردن Resource.

سوال Product Owner

در یک سال آینده انتظار چه رشدی داریم؟ ۱۰ هزار کاربر؟ ۱ میلیون کاربر؟ یا رشد شدید در Data Volume؟

Metrics مهم

Throughput
RPS / TPS
Concurrent Users
CPU/Memory Utilization

مثال: اگر سیستم برای ۱۰۰ کاربر سریع است ولی با ۱۰۰ هزار کاربر کند می‌شود، مشکل اصلی احتمالاً Performance نیست؛ مشکل Scalability است. شاید نیاز به Load Balancer، Stateless Service، Cache یا Partitioning داشته باشیم.

Scale Up

یعنی قوی‌تر کردن همان Server: CPU بیشتر، RAM بیشتر، Disk سریع‌تر. ساده‌تر است، ولی سقف دارد.

Scale Out

یعنی اضافه کردن چند Server یا Pod و پخش کردن Load. پیچیده‌تر است، ولی برای رشد جدی معمولا مسیر درست‌تری است.

Patterns

Load Balancing
Sharding
Stateless Services
CQRS
Event-driven Design

Anti-patterns

Monolithic Bottlenecks
Sticky Sessions
Single DB for Everything
Global Shared State
Only Replication without Partitioning

Availability

Uptime

Availability یعنی سیستم چه درصدی از زمان سالم و قابل استفاده است. این همان چیزی است که کاربر خیلی ساده می‌گوید: «سایت بالا هست یا نه؟»

سوال Product Owner

قطعی یک ساعته چه هزینه‌ای دارد؟ آیا ساعت خاصی مثل کمپین، پرداخت، پخش زنده یا روزهای پرترافیک critical است؟

Metrics مهم

Uptime
99.9%
99.99%
MTBF
MTTR

مثال: 99.99% Availability یعنی حدود ۵۲ دقیقه downtime در سال. این عدد قشنگ است، ولی هزینه دارد: Redundancy، Failover، Monitoring، On-call و تست جدی.

Patterns

Redundancy
Failover
Replication
Health Checks
Blue/Green Deployment
Graceful Degradation

Anti-patterns

Single Point of Failure
Manual Failover
Long Maintenance Downtime
Silent Failures
Retry Storm

Resiliency

Recover gracefully

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

سوال Product Owner

اگر Payment provider قطع شد، کاربر چه چیزی ببیند؟ اگر Search کند شد، آیا کل اپ باید fail شود یا فقط Search محدود شود؟

Metrics مهم

MTTR
Blast Radius

مثال: در سیستم سفارش، اگر سرویس Notification قطع شد، سفارش نباید fail شود. سفارش ثبت می‌شود، پیام در Queue می‌ماند و Notification بعداً ارسال می‌شود.

Patterns

Circuit Breaker
Bulkhead Isolation
Timeout + Retry + Fallback
Chaos Testing
Graceful Degradation

Anti-patterns

Cascading Failures
Assuming Reliable Network
Shared Failure Domains
No Isolation
Single Point of Failure

Consistency

Correct view of data

Consistency یعنی رفتار و داده سیستم برای کاربران مختلف چقدر یکسان و قابل اعتماد دیده می‌شود. سوال اصلی: آیا همه باید همان لحظه دقیقاً یک حقیقت واحد ببینند؟

سوال Product Owner

تغییر یک کاربر چقدر سریع باید برای دیگران دیده شود؟ اگر چند ثانیه Data قدیمی دیده شود، آیا مشکل UX است یا مشکل مالی و حقوقی؟

Metrics مهم

Data Replication Lag
Rate of Stale Reads

مثال قابل قبول: تعداد Like یک پست می‌تواند چند ثانیه با تأخیر Sync شود. اینجا Eventual Consistency قابل قبول است.

مثال غیرقابل قبول: موجودی کیف پول، تراکنش بانکی یا ظرفیت نهایی خرید نباید با Data قدیمی تصمیم‌گیری شود. اینجا Strong Consistency یا Transaction دقیق لازم است.

Patterns

Strong Consistency
Eventual Consistency
ACID Transactions
Consensus Algorithms
Saga

Anti-patterns

Strong Consistency Everywhere
Cache Invalidation Bugs
Stale Reads
No Single Source of Truth
Split-Brain

Observability

Understand what happened

Observability یعنی بتوانیم درباره سیستم سوال جدید بپرسیم، بدون اینکه مجبور شویم دوباره Code منتشر کنیم. یعنی وقتی Incident شد، فقط حدس نزنیم؛ سند داشته باشیم.

سوال Product Owner

وقتی کاربر گفت پرداخت من مشکل داشت، چقدر سریع می‌فهمیم چه اتفاقی افتاده؟ User، Request، Service، DB و Provider قابل Trace هستند؟

Metrics مهم

Mean Time to Detect
Traceability
Alert Quality

مثال: هر Request یک Correlation ID دارد. همان ID در API Gateway، Backend Service، Queue Worker و Log مربوط به Payment Provider ثبت می‌شود. حالا Debug کردن شبیه کارآگاهی است، نه احضار روح.

Patterns

Metrics & Dashboards
Structured Logging
Distributed Tracing
Correlation IDs
Alerting

Anti-patterns

Logging Too Little
Logging Too Much
Unstructured Logs
Logs without Context
Alert Fatigue

Reliability

Trustworthy behavior

Reliability یعنی سیستم قابل اعتماد و predictable باشد. فقط بالا بودن سیستم کافی نیست؛ باید درست هم کار کند.

سوال Product Owner

کدام قابلیت‌ها باید همیشه درست کار کنند؟ Failure قابل قبول برای Featureهای مختلف چقدر است؟

Metrics مهم

MTBF
Failure Rate
Error Rate

مثال: اگر سیستم پرداخت ۹۹.۹۹٪ Availability داشته باشد ولی گاهی دوبار شارژ کند، Reliable نیست. Availability خوب است؛ ولی Reliability یعنی خروجی درست و قابل اعتماد.

Patterns

Automated Testing
Fault Isolation
Timeout + Retry + Fallback
Chaos Testing
Graceful Degradation

Anti-patterns

Silent Failures
Lack of Error Handling
Insufficient Testing
No Isolation
Single Point of Failure

Trade-offs

No free lunch

در System Design هر انتخابی هزینه دارد. اگر همه چیز را همزمان بخواهیم، معمولاً یک هیولای گران، کند و پیچیده می‌سازیم که فقط در جلسه معماری قشنگ است.

NFR Conflict	توضیح ساده	مثال
Performance vs Reliability	گاهی برای درست بودن، سرعت را قربانی می‌کنیم.	در Banking System، ACID Transaction ممکن است latency را بالا ببرد، ولی correctness مهم‌تر است.
Consistency vs Scalability	Strong Consistency در همه جا، Scale کردن را سخت‌تر می‌کند.	Timeline شبکه اجتماعی می‌تواند Eventual Consistency داشته باشد تا سریع‌تر و Scaleپذیرتر شود.
Availability vs Consistency	گاهی در قطعی شبکه باید بین همیشه آنلاین بودن و همیشه دقیق بودن انتخاب کنیم.	Catalog فروشگاه ممکن است قیمت Cache شده نشان دهد، ولی checkout باید دقیق باشد.
Scalability vs Observability	Telemetry زیاد خودش overhead و cost دارد.	Tracing برای همه requestها شاید گران باشد؛ Sampling می‌تواند تعادل ایجاد کند.
Availability vs Resiliency	Health Check اشتباه می‌تواند Pod سالم اما کند را بی‌دلیل kill کند.	در Kubernetes، Probe خیلی حساس ممکن است خودش باعث اختلال شود.

🎯

تصمیم درست، تصمیم contextual است

برای Payment، Consistency و Reliability جلوترند. برای Feed یا Banner، Performance و Availability ممکن است مهم‌تر باشند. برای Platform داخلی، Observability و Maintainability معمولاً حیاتی‌اند.

مسیر رشد Architecture با رشد User

Architecture Evolution

معماری قرار نیست از روز اول Microservices، Sharding و Kafka داشته باشد. معماری خوب با Stage محصول رشد می‌کند؛ نه با هیجان جلسه.

Simple Monolith

برای شروع، یک Monolith تمیز با DB درست، Logging و تست پایه کافی است.

Load Balancer

چند instance، Health Check و Stateless شدن مسیرهای اصلی.

Caching

Cache برای read-heavy pathها، CDN برای assetها و کاهش فشار DB.

Microservices

جدا کردن domainهایی که ownership، scale یا release cycle متفاوت دارند.

Sharding / Federation

Partition کردن Data و Workload وقتی یک DB یا Cluster دیگر جواب نمی‌دهد.

Meta Patterns

Reusable design moves

Meta Patternها حرکت‌های تکرارشونده در معماری هستند. اسم‌ها را حفظ نکنید؛ کاربردشان را بفهمید.

Meta Pattern	معنی کوتاه	Tech Example	مثال روزمره
Decompose	سیستم را به بخش‌های قابل مدیریت تقسیم کن.	Microservices by business domain	تقسیم شرکت به دپارتمان‌ها
Partition	Data یا Workload را با key یا range تقسیم کن.	Sharded MongoDB Cluster	تقسیم پرونده دانش‌آموزان بین مدارس
Encapsulate	پیچیدگی داخلی را پشت Interface تمیز پنهان کن.	REST API around internal logic	آشپزخانه رستوران پشت پیشخوان
Replicate	Data یا Service را برای Scale یا Fault Tolerance تکرار کن.	Primary-replica PostgreSQL	کپی گرفتن از مدارک مهم
Defer	کار غیرضروری را عقب بینداز.	Order processing via Queue	گذاشتن ظرف‌ها در ماشین ظرف‌شویی
Cache / Memoize	نتیجه را نگه دار تا دوباره محاسبه نکنی.	Redis caching API responses	نگه داشتن غذای اضافه در یخچال
Monitor / Observe	سلامت، Performance و Correctness را پایش کن.	Prometheus + Grafana	داشبورد سرعت ماشین
Isolate	Fault یا Side-effect را محدود کن.	Separate process pools	درب ضدحریق بین بخش‌های ساختمان
Coordinate	برای Correctness بین بخش‌ها توافق ایجاد کن.	Consensus / DB Transactions	رأی‌گیری خانواده برای شام
Contract-Based Design	قانون تعامل را شفاف و enforce کن.	OpenAPI / gRPC Contracts	قرارداد حقوقی بین دو شرکت

Checklist تصمیم‌گیری NFR

Use in grooming / architecture review

۱. اول Business Impact را بپرس

کندی، قطعی یا Data اشتباه دقیقاً چه ضرری دارد؟ ضرر مالی؟ نارضایتی کاربر؟ ریسک امنیتی؟ هزینه پشتیبانی؟

۲. Journeyهای Critical را جدا کن

همه مسیرها یکسان نیستند. Login، Payment، Checkout، Search و Report هرکدام NFR متفاوت دارند.

۳. Metric قابل اندازه‌گیری تعریف کن

«سریع باشد» یعنی هیچ. بگو p95 زیر چند ms؟ Error Rate چند درصد؟ MTTR چقدر؟

۴. Trade-off را شفاف کن

اگر Consistency را بالا می‌بریم، Latency و Complexity چه می‌شود؟ اگر Availability می‌خواهیم، هزینه Redundancy چقدر است؟

۵. Pattern را با نیاز انتخاب کن

Queue، Cache، Circuit Breaker، Sharding و Microservice ابزار هستند؛ هدف نیستند.

۶. Observability را حذف نکن

بدون Metrics، Logs، Traces و Alerting، NFRها بیشتر شبیه آرزو هستند تا Requirement.

Template ساده برای Jira یا RFC: این Feature برای Performance نیاز دارد p95 زیر ۵۰۰ms باشد، برای Availability باید در زمان کمپین بدون downtime کار کند، و برای Consistency در مرحله پرداخت باید Strong Consistency داشته باشد.