محاسبات لبه‌ای در هاستینگ؛ معماری، سرعت، امنیت و هزینه

کد را به «Edge» منتقل می‌کنید، اما برای هر درخواست هنوز باید به دیتابیس دوردست وصل شود. یک رفت‌وبرگشت نزدیک حذف شده و سه Subrequest دور اضافه شده است؛ TTFB بدتر می‌شود. یا احراز هویت را در چند نقطه توزیع می‌کنید، اما لغو Token با تأخیر پخش می‌شود. برچسب Edge به‌تنهایی سرعت، امنیت یا پایداری ایجاد نمی‌کند؛ فقط محل اجرای بخشی از سیستم را تغییر می‌دهد.

محاسبات لبه‌ای در هاستینگ وب یک تصمیم Placement است: کدام Cache، Code، State و Data با چه Consistency و Failure contract نزدیک کاربر اجرا شود و چه چیزی در Region/Origin بماند. این راهنما Edge را از CDN، Cloud و Serverless جدا می‌کند و از Latency decomposition تا State، Security، Observability، Cost، ایران، Pilot و Rollback پیش می‌رود.

Edge یک مکان مطلق نیست

«لبه» نسبت به سیستم تعریف می‌شود. برای یک سایت، PoP شبکه توزیع محتوا Edge است؛ برای کارخانه، Gateway داخل سایت؛ برای اپ موبایل، خود Device یا شبکه اپراتور. عبارت «نزدیک کاربر» باید با Topology و RTT واقعی اثبات شود، نه نقشه بازاریابی Provider.

Edge و Cloud رقیب دودویی نیستند. بیشتر معماری‌های واقعی یک Continuum دارند: Static asset در Edge cache، Routing در Edge function، API در Region و تراکنش در Database اصلی.

CDN، Edge Compute، Serverless و Multi-region چه تفاوتی دارند؟

CDN امروز می‌تواند Programmatic باشد و Edge platform نیز Cache ارائه کند؛ مرز محصولی Providerها هم‌پوشان است. برای معماری پیشرفته Cache، Origin shielding، Edge function و عملیات CDN، راهنمای CDN پیشرفته مالک جزئیات است. این مقاله تصمیم Placement کل Workload را پوشش می‌دهد.

از Workload contract شروع کنید

Journey: جست‌وجوی محصول از تهران
Population: guest and signed-in mobile users
Current path: ISP → CDN → Frankfurt app → Frankfurt DB
Baseline p50/p75/p95 TTFB: 420/710/1480 ms
Candidate edge job: query normalization + cache-safe routing
State: none; catalog response cached by locale/category/version
Correctness: no user-specific price in shared cache
Primary: p75 TTFB and search success
Guardrails: stale stock, wrong currency, 5xx, origin load, cost/request
Fallback: bypass edge function to regional API
Owner / expiry: Platform / 1405-08-30

Latency هدف نیست اگر نتیجه اشتباه باشد. Journey، Population، Data class، Read/write ratio، Consistency، Runtime، Failure، Cost و Exit را هم‌زمان ثبت کنید.

Latency را به اجزا بشکنید

Total response path
= DNS
+ connect + TLS
+ edge queue
+ edge compute
+ edge→data/region subrequests
+ regional queue/compute
+ database/dependency
+ response transfer
+ browser processing/render

Edge معمولاً بخش User→compute را کوتاه می‌کند؛ اگر Data دور بماند، Edge→Data به Critical path اضافه می‌شود. Cache hit می‌تواند جهش بزرگی بسازد؛ Cache miss، cold code path، TLS مجدد یا Dependency خارجی ممکن است سود را از بین ببرد.

• RTT و Time-to-first-byte را بر Country/ASN/ISP/Device/Cache status اندازه بگیرید.
• p50 را تنها گزارش نکنید؛ p75/p95/p99 و Failure rate مهم‌اند.
• Server-Timing/Trace span برای Edge، Region، DB و Dependency بسازید.
• Warm/cold، hit/miss، guest/signed-in و read/write را جدا کنید.
• Baseline را با همان Payload، Data و Traffic profile مقایسه کنید.

TTFB بهتر لزوماً LCP یا Conversion بهتر نیست

Edge می‌تواند پاسخ HTML/API را زودتر برساند، اما LCP هنوز به Resource discovery، تصویر/فونت، CSS، JavaScript، Render و Device وابسته است. Personalization لبه‌ای ممکن است HTML را غیرقابل‌Cache یا Hydration را سنگین کند و سود شبکه را پس بگیرد.

برای سنجش Field و Lab معیارهای LCP/INP/CLS به راهنمای Core Web Vitals و RUM متصل شوید. رتبه یا Conversion را از TTFB استنتاج نکنید؛ Outcome را با Cohort/Experiment و Guardrail بسنجید.

چه کارهایی نامزد خوب Edge هستند؟

Routing و Redirect: ساده اما Blast radius بالا

Locale، legacy redirect، canonical host، device capability یا maintenance routing می‌توانند در Edge اجرا شوند. Rule باید deterministic، bounded و قابل خاموش‌کردن باشد.

routing acceptance
- normalized host/path before match
- no open redirect
- max one internal rewrite + one external redirect
- query allowlist; sensitive params stripped
- locale preference does not force IP-only decision
- bot/user parity for equivalent content
- signed config + version + staged rollout
- loop/404/5xx/canonical regression set
- bypass header available only to authorized operations

استفاده از IP geolocation برای زبان یا نسخه محتوا باید Override کاربر و URL پایدار داشته باشد. نمایش محتوای متفاوت به Bot و User می‌تواند تشخیص/اعتماد را خراب کند.

Cache contract قبل از Edge code

RFC ۹۱۱۱ درباره HTTP Caching Freshness، Cache key، Vary، Validation و Invalidation را تعریف می‌کند. Edge function نباید Headerهای Origin را بی‌دلیل نادیده بگیرد یا پاسخ authenticated را وارد Shared cache کند.

پاسخ قیمت، موجودی، Session یا حساب کاربر را با Cache key ناقص عمومی نکنید. «Purge شد» نیز تا وقتی در چند PoP/ISP و URL variant تأیید نشده، Evidence کامل نیست.

State را چهار دسته کنید

1. Stateless/request-local: Parse، routing، transform؛ Fit ساده‌تر.
2. Read-mostly replicated: Config، catalog snapshot، allowlist؛ Staleness budget لازم.
3. Session/user state: preference، cart، auth؛ privacy/consistency/ownership حساس‌تر.
4. Transactional/global state: inventory reservation، payment، ledger؛ Atomicity/idempotency/conflict تعیین‌کننده.

هرچه Write و Conflict بیشتر، انتقال بی‌فکر به Edge پرریسک‌تر است. Compute نزدیک بدون Data نزدیک فقط Proxy دیگری می‌سازد.

Consistency یک Trade-off قابل‌مشاهده است

مدل‌ها را دقیق بنویسید: Eventual، read-your-writes/session، per-key serial/strong یا transaction محدود. نام «Edge DB» هیچ ضمانت یکنواختی نمی‌دهد. مستند جاری Cloudflare Workers KV برای نمونه آن را read-heavy و Eventually consistent معرفی می‌کند و می‌گوید تغییر در نقاط دیگر ممکن است تا ۶۰ ثانیه یا بیشتر دیده نشود؛ این ویژگی برای Config قابل‌قبول و برای لغو دسترسی فوری شاید نامناسب باشد.

Write path را جدا از Read path طراحی کنید

Read را می‌توان Replicate/Cache کرد، اما Write نیازمند Authority و Idempotency است. یک Pattern رایج: Edge ورودی را Validate و Route می‌کند، Command دارای Idempotency key را به Region owner می‌فرستد، نتیجه Canonical ثبت و Read model بعداً پخش می‌شود.

POST /orders
Edge: auth + size/rate/input validation
  → region owner by customer/order key
  → idempotent command(order_request_id)
  → transactional inventory/payment state
  → canonical response + trace ID
  → async read-model/cache invalidation

Never acknowledge success at edge before authoritative commit.

Queue یا asynchronous write می‌تواند Availability ظاهری را بالا ببرد، اما UX باید Pending/Confirmed/Failed و Compensation را نشان دهد. پذیرش درخواست با تکمیل سفارش یکی نیست.

Runtime و Provider را از روی نام انتخاب نکنید

Runtimeهای Edge ممکن است V8 isolate، Web API subset، container یا Region-optimized function باشند. Filesystem، socket، native module، dynamic code، execution time، request body، concurrency، log و network access متفاوت‌اند. مستند رسمی باید در روز تصمیم Snapshot شود.

برای نمونه، مستند جاری Cloudflare Workers اجرای توزیع‌شده در V8 isolate و عدم تضمین ماندگاری Instance/global mutable state را توضیح می‌دهد. مستند فعلی Vercel Edge Runtime حتی مهاجرت Edge به Node.js را برای Performance/Reliability بهتر توصیه می‌کند و API subset/limit دارد. Lambda@Edge restrictions نیز Region، Feature، Body و Runtime محدودیت‌های خاص خود را دارد. این تفاوت‌ها نشان می‌دهند «Edge Function» یک SKU استاندارد نیست.

Compatibility harness بسازید

برای انتخاب کلی VM/PaaS/FaaS/BaaS و Workload/TCO، مقالهٔ سرورلس یا سرور سنتی مرجع مکمل است.

امنیت Edge ذاتاً بیشتر نیست

Edge می‌تواند DDoS absorption، WAF، rate limit و input filtering را قبل از Origin اجرا کند؛ هم‌زمان Secret، Code، Config، Log و Policy را در Control/data plane بیشتری توزیع می‌کند. NIST در SP 800-207A تأکید می‌کند Location، affiliation یا ownership مبنای اعتماد ضمنی نیست. «نزدیک شبکه» مساوی Trusted نیست.

• هر Function یک Service identity با Least privilege و Egress allowlist داشته باشد.
• Secret در Code/bundle/log نباشد؛ Rotation و revocation آزموده شود.
• Request/Body/Header/URL و Event ورودی Validate و Size-bound شوند.
• Image/proxy/fetch برای جلوگیری از SSRF دارای origin/port/protocol allowlist باشد.
• Rate limit را بر Identity/route/risk و با False-positive recovery طراحی کنید.
• Dependency و artifact امضاشده، SBOM و deploy provenance داشته باشند.
• WAF را جای Authorization/validation/business rule نگیرید.

OWASP Serverless/FaaS Security Cheat Sheet ریسک‌هایی مانند IAM بیش‌ازحد، ورودی نامعتبر، Function chaining، Secret و Egress باز را یادآوری می‌کند.

Auth در Edge: Verify با Authorization فرق دارد

تأیید Signature یک JWT با Key cache‌شده می‌تواند نزدیک کاربر انجام شود؛ تصمیم Authorization ممکن است به Role/entitlement/revocation تازه نیاز داشته باشد. Contract بنویسید:

• Issuer/Audience/Algorithm/Expiry/clock skew و key ID؛
• Key refresh و رفتار Unknown key؛
• Revocation/role-change propagation budget؛
• Fail-open یا fail-closed بر اساس Action risk؛
• Replay، token binding/context و log redaction؛
• Origin دوباره چه کنترل‌هایی را enforce می‌کند.

برای مشاهده محتوای عمومی شاید stale entitlement کم‌ریسک باشد؛ برای پرداخت، پنل ادمین یا حذف داده، Authorization authoritative لازم است.

Edge و حریم خصوصی/Data residency

پردازش نزدیک کاربر می‌تواند Data minimization محلی بسازد، اما Deploy جهانی ممکن است درخواست، Cookie، IP، Log یا State را به Jurisdictionهای بیشتری ببرد. «داده در Edge می‌ماند» را بدون Data-flow evidence نگویید.

Reliability: Node بیشتر، Failure mode بیشتر

وجود صدها PoP آپتایم ۱۰۰٪ را تضمین نمی‌کند. Anycast/BGP، DNS، Control-plane deploy، config propagation، certificate، Edge runtime، regional dependency، database و Origin هرکدام Failure دارند. یک تغییر Policy می‌تواند همه PoPها را هم‌زمان خراب کند.

Failure contract:

Failure: edge function timeout
Detect: route×PoP×version 5xx and latency SLO burn
Fallback: bypass to region for eligible routes
Timeout budget: edge 50ms CPU / 300ms wall policy (example only)
Retry: max 1, only idempotent, jittered, within end-to-end deadline
Stale: public catalog only; never payment/account state
Rollback: previous immutable bundle + config version
Exit: DNS/origin path tested monthly

Timeout/retry/circuit breaker باید end-to-end budget داشته باشند؛ Retry در Browser، Edge و Region می‌تواند Load را چند برابر کند. Availability مستقل را با مانیتورینگ آپتایم و Recovery را با بازیابی فاجعه و Restore drill پوشش دهید.

Observability باید از Edge تا Data پیوسته باشد

PoP code، User ID یا raw URL را بی‌قاعده Label نکنید. Sampling باید Trace خطا و Tail را حفظ کند. برای SLO، Metric/Log/Trace و Alert، راهنمای Observability را اجرا کنید.

SEO و Cache/Geo correctness

• Googlebot و کاربر برای URL یکسان باید Status/Canonical/robots/محتوای معادل ببینند.
• Redirect locale فقط بر IP نباشد؛ URL پایدار و انتخاب کاربر وجود داشته باشد.
• Cache key نباید Canonical یا hreflang مربوط به کشور دیگری را نشت دهد.
• Personalization سنگین، محتوای اصلی و Internal link را از HTML قابل‌خزش حذف نکند.
• Soft ۴۰۴/5xx/timeout Edge را بر User-agent خاص مخفی نکنید.
• Deployment و Purge را با Synthetic crawl از چند منطقه تأیید کنید.

Edge راه‌حل مستقل SEO نیست؛ Correctness، Crawlability و Performance واقعی مهم‌اند. Dynamic rendering یا Bot branching بدون ضرورت، عملیات و ریسک Cloaking را بالا می‌برد.

TCO محاسبات لبه‌ای

Edge monthly TCO
= requests/invocations
+ CPU and wall/active time pricing
+ subrequests and data operations
+ storage/replication/read/write
+ egress/origin/CDN traffic
+ logs/metrics/traces retention/export
+ build/deploy/security/support plan
+ engineering/on-call/testing/incident time
+ migration/dual-run/exit cost
+ FX/tax/payment/contract risk
- verified origin/bandwidth/latency/incident savings

قیمت واحد کم با Invocation زیاد، Log حجیم یا KV read می‌تواند پرهزینه شود. Provider ممکن است Billing model یا Runtime recommendation را تغییر دهد. Cost/request، Cost/qualified journey و Cost/region را با Budget/alert بسنجید؛ راهنمای مدیریت هزینه کلود و FinOps این لایه را عمیق‌تر پوشش می‌دهد.

Vendor scorecard و Exit

Proof of concept باید از Code و Traffic شبیه Production استفاده کند. Vendor benchmark عمومی، مسیر شبکه و Data gravity شما را نمایندگی نمی‌کند.

نسخه ایران: Topology را اندازه بگیرید

برای مخاطب ایران، نزدیک‌ترین PoP روی نقشه الزاماً کوتاه‌ترین Route نیست. Peering، اپراتور، DNS resolver، Anycast/BGP، اختلال مقطعی، TLS و مسیر بین‌الملل نتیجه را تغییر می‌دهند.

• از چند اپراتور موبایل، اینترنت ثابت، شهر و ساعت Probe کنید.
• DNS/connect/TLS/TTFB/download را جدا ثبت کنید.
• PoP/colo واقعی و Origin/DB dependency را در Trace ببینید.
• Provider داخلی/خارجی را با همان Cache/Compute/Security contract مقایسه کنید.
• Data location، Contract، دسترسی حساب، پرداخت، تحریم، Export و Support را حقوقی/عملیاتی بسنجید.
• ریال/تومان، نرخ ارز و Scenario افزایش مصرف/قیمت را در TCO بیاورید.
• DNS/Origin bypass یا Provider دوم را امن، محدود و تمرین‌شده نگه دارید.

برای انتخاب و راه‌اندازی Cache delivery در ایران، راهنمای CDN برای سایت ایرانی را به این Topology assessment وصل کنید.

پنج سناریوی معماری

سایت محتوایی عمومی

HTML/asset cache با versioned purge و stale محدود، بیشترین ارزش اولیه را دارد. Edge code را به redirect/security header/experiment assignment کوچک محدود کنید. CMS/DB در Origin بمانند.

فروشگاه با موجودی و قیمت متغیر

Category/page shell و تصویر Cache می‌شوند؛ قیمت/موجودی با Staleness budget کوتاه یا Region API می‌آیند. Cart/payment write به سرویس authoritative و Idempotent می‌رود. Shared cache هرگز User-specific price را نگه ندارد.

SaaS با کاربران چندمنطقه‌ای

Static shell، auth signature verify و routing می‌توانند Edge باشند؛ Tenant data و authorization policy به Data residency/consistency وابسته‌اند. Region pinning و tenant→region map با failover contract لازم است.

Image optimization service

Source domain/format/dimension allowlist، signed transform URL، object cache، size/CPU budget و SSRF defense بسازید. Transform on-demand را با pre-generation و CDN hit ratio مقایسه کنید.

A/B test در Edge

Assignment پایدار، consent، bot parity، cache key و exposure event لازم‌اند. Variant باید Canonical/robots/heading اصلی را ناخواسته تغییر ندهد. Holdout و rollback در Config version باشد.

Migration با Vertical slice

1. یک Route read-only و برگشت‌پذیر انتخاب کنید.
2. Baseline latency/correctness/origin load/cost را ثبت کنید.
3. Function stateless با Fallback و Trace بسازید.
4. Shadow یا ۱٪ Traffic روی PoP/ISP محدود اجرا کنید.
5. ۵→۲۵→۵۰→۱۰۰٪ فقط با SLO/guardrail سالم افزایش دهید.
6. State/data را در Pilot اول منتقل نکنید مگر Use case همان باشد.
7. Rollback و bypass را در Game day واقعی تمرین کنید.

Runbook ۱: یک PoP یا ISP کند است

1. PoP/ASN/ISP/route/version/cache status را Segment کنید.
2. DNS/TLS/edge queue/compute/subrequest/region/DB را از Trace جدا کنید.
3. Provider status/BGP و Synthetic چندشبکه‌ای را مقایسه کنید.
4. Route را به PoP/Region سالم Shift یا Edge function را Bypass کنید.
5. Recovery را بر p95 و correctness تأیید و Root cause ثبت کنید.

Runbook ۲: محتوای خصوصی در Cache دیده شد

1. Route/keys/variant را Contain و Shared caching را فوراً خاموش کنید.
2. Purge سراسری و چندنقطه‌ای را با Evidence تأیید کنید.
3. Data class، Authorization، Cache-Control/Vary/key و Log exposure را Scope کنید.
4. Incident/privacy/legal notification path را فعال و Token/secret لازم را Rotate کنید.
5. private/no-store regression و canary gate را پیش از بازگشت اضافه کنید.

Runbook ۳: Edge سریع است اما DB کندتر شده

1. Subrequest count، connection reuse، query و fan-out را اندازه بگیرید.
2. Edge→DB RTT و concurrent connection amplification را مقایسه کنید.
3. Aggregation/parallelism را bounded و Cache/read model را بررسی کنید.
4. Compute را به Data region برگردانید یا region owner تعریف کنید.
5. End-to-end p95 و DB saturation را قبل از Rollout تأیید کنید.

Runbook ۴: Config جدید همه مناطق را خراب کرد

1. توزیع Config را Freeze و نسخه قبلی immutable را فعال کنید.
2. Propagation state و PoPهای سالم/ناسالم را مشاهده کنید.
3. Fail-safe default و config TTL/validation/signature را بررسی کنید.
4. Canary by account/PoP/percentage و automated rollback اضافه کنید.
5. Control-plane game day و separation of duties را تکمیل کنید.

Runbook ۵: هزینه Edge ناگهان بالا رفت

1. Billing meter را بر route/version/PoP/customer class تفکیک کنید.
2. Loop، retry، bot/abuse، cache miss، subrequest و log volume را بررسی کنید.
3. Spend cap/rate limit/sampling/cache و expensive feature flag را اعمال کنید.
4. Unit cost را با Outcome و Origin savings Reconcile کنید.
5. Forecast و anomaly threshold را به Deploy gate اضافه کنید.

برنامه ۳۰، ۶۰ و ۹۰ روزه

روز ۱ تا ۳۰: Baseline و Map

Journey/route/dependency/data map، RTT و TTFB breakdown، Cache status، SLO، Cost و Failure inventory را بسازید. Workloadها را Stateless/Read-mostly/Session/Transactional طبقه‌بندی و یک Route کم‌ریسک انتخاب کنید.

روز ۳۱ تا ۶۰: Pilot و Operations

Vertical slice با Trace، config version، security controls، Cache contract، timeout/retry budget، Bypass و immutable rollback بسازید. روی چند ISP/شهر/دستگاه ایران و بخشی از Traffic اجرا کنید.

روز ۶۱ تا ۹۰: Scale یا Exit

Latency/Correctness/Availability/Origin load/Cost/User outcome را با Baseline مقایسه کنید. اگر Gateها سالم‌اند Routeهای مشابه را مرحله‌ای منتقل کنید؛ اگر Data gravity یا TCO بد است Compute را به Region برگردانید. DR، cost anomaly و control-plane Game day برگزار کنید.

چک‌لیست تصمیم Edge

• Edge نسبت به Device/PoP/Region/Origin تعریف شده است.
• Journey، Workload، Read/write، Data class و SLO روشن‌اند.
• Latency به DNS/TLS/compute/subrequest/DB/render شکسته شده است.
• Cache eligibility/key/freshness/stale/invalidation/privacy قرارداد دارد.
• State owner، consistency، conflict، stale budget و fallback مشخص‌اند.
• Write authoritative، Idempotency و Pending/Failure UX دارد.
• Runtime/API/library/limit/network سازگاری با Artifact واقعی تست شده است.
• IAM/secret/egress/input/SSRF/rate/artifact controls فعال‌اند.
• Data flow/location/log/retention/delete و قانون/قرارداد بررسی شده‌اند.
• Trace/metric/log/correctness/cost بر PoP/route/version حاضرند.
• SEO status/canonical/robots/locale/cache parity آزموده شده است.
• TCO همه Meterها، تیم، FX و Exit را دارد.
• چند اپراتور/شهر/ساعت ایران اندازه‌گیری شده‌اند.
• Canary، feature flag، bypass، rollback و Game day وجود دارند.

پرسش‌های متداول

Edge Computing دقیقاً چیست؟

تصمیمی معماری برای اجرای Cache، Code یا Data نزدیک‌تر به منبع درخواست/کاربر است. «نزدیک» نسبی و شبکه‌ای است. Edge معمولاً Cloud/Origin را حذف نمی‌کند؛ وظایف را میان Device، PoP، Region و Data authority تقسیم می‌کند.

تفاوت Edge Computing و CDN چیست؟

CDN عمدتاً قرارداد Cache/Delivery Representation بر HTTP است؛ Edge compute منطق برنامه را در نقاط توزیع‌شده اجرا می‌کند. محصولات مدرن هر دو را ترکیب می‌کنند، پس مرز تجاری هم‌پوشان است. تفاوت واقعی را با Cache، Runtime، State و Consistency contract بسنجید.

آیا Edge همیشه سایت را سریع‌تر می‌کند؟

خیر. اگر پاسخ Cache شود یا Logic مستقل از Data دور باشد می‌تواند سریع‌تر شود؛ Fan-out، DB دور، cold path، Runtime limit یا Personalization غیرقابل‌Cache ممکن است کندتر کند. End-to-end p75/p95 روی ISP/Device واقعی را با Baseline مقایسه کنید.

آیا Edge امنیت و آپتایم را تضمین می‌کند؟

خیر. Edge می‌تواند WAF/rate-limit/DDoS absorption و Failover را تقویت کند، اما Control plane، IAM، Secret، Cache leakage، Config propagation و dependency failure اضافه می‌کند. Zero Trust، SLO، observability، rollback و DR همچنان لازم‌اند.

برای سایت ایرانی از کجا شروع کنیم؟

ابتدا چندشبکه‌ای DNS/TLS/TTFB/PoP/Origin را اندازه بگیرید و Cache عمومی را درست کنید. سپس یک Route read-only و stateless با Fallback و Trace Pilot کنید. Provider داخلی/خارجی را با Route واقعی، Contract، TCO ریالی/ارزی، Data flow، Export و Exit بسنجید.

جمع‌بندی: Edge را نزدیک Data و تصمیم نگه دارید

محاسبات لبه‌ای جهش کوانتومی یا الزام بقای هر هاست نیست. وقتی Cache/Logic درست نزدیک کاربر قرار گیرد و State authority، Consistency، Security، Failure و Cost روشن باشند، می‌تواند Latency و Origin load را کم کند. وقتی Code نزدیک اما Data دور، Write مبهم یا Control plane بی‌مهار باشد، فقط سیستم توزیع‌شده گران‌تری ساخته‌اید. از Workload کوچک، Evidence چندشبکه‌ای، Feature flag و Rollback آغاز کنید؛ Placement موفق آن است که Correctness و Outcome را با کمترین پیچیدگی کل سیستم بهبود دهد.