گاهی جواب دقیق خیلی گران است، اما جواب تقریبی کاملاً کافی است: «آیا احتمالاً این لینک قبلاً دیده شده؟»، «حدوداً چند کاربر یکتا داشتیم؟» یا «کدام کالا خیلی داغ است؟». ساختارهای احتمالاتی با حافظه کم، چنین جوابهایی میدهند و باید خطای آنها را بشناسیم.
Mesh ابزار است، نه جای طراحی
Mesh میتواند mTLS، timeout policy، canary traffic و trace context را استاندارد کند، ولی idempotency، authorization دامنه، budget retry و ownership داده را حل نمیکند. retry پنهان mesh روی POST غیر-idempotent یا timeout نامناسب میتواند آسیب را بیشتر کند. ابتدا قراردادهای سرویس و observability را درست کن، سپس mesh را وقتی پیچیدگی عملیاتیاش توجیه دارد اضافه کن.
به زبان ساده
بعضی جوابها را تقریبی و ارزان میگیریم (مثلاً «احتمالاً دیدهام») ولی اندازه خطایش را میدانیم؛ Service Mesh هم کارهای مشترک سرویسها را میگیرد، نه منطق دامنه را.
مثال واقعی
Bloom Filter جلوی دیتابیس جستجو: اگر گفت «SKU قطعاً نیست» مستقیم پاسخ میدهی و سراغ DB نمیروی؛ اگر گفت «شاید هست»، تازه DB را چک میکنی.