ByteHeavy
ByteHeavy
ByteHeavy
نمونهکار
چون هنوز در ابتدای مسیر عمومیسازی پورتفولیوی مشتریها هستیم، اینها نمونهی نوع مهندسیای هستن که انجام میدیم — نه ادعای پروژه مشتری خاص.
TypeScript، Postgres، Redis
ساختهشده برای یک کامیونیتی دیسکورد متوسط که به یک سیستم ارز داخلسرور نیاز داشت، بدون اکسپلویتها و race condition هایی که اکثر رباتهای اقتصاد «سریع» رو اذیت میکنه. هر تغییر موجودی داخل یک تراکنش دیتابیس serializable پیچیده شده، پس دو معامله همزمان نمیتونن همون سکهها رو دوبار خرج کنن — دقیقاً همون کلاس باگی که بیشتر از هر هکر خارجیای، بیسروصدا اقتصاد سرورهای دیسکورد رو ورشکست کرده. اقدامات حساس ادمین (تغییر موجودی، اعطای آیتم، بن کردن) توی یک audit trail غیرقابلتغییر ثبت میشن، پس هر اختلافی یک ردپای مستند داره، نه یک بحث «من گفتم، تو گفتی». کل سیستم زیر بار همزمان اوج تست شده — هزاران تعامل توی همون چند دقیقه یک رویداد کامیونیتی — بدون اینکه هیچوقت به محدودیت نرخ API خود دیسکورد بخوره، چون صف درخواستها قبل از رسیدن به سرور دیسکورد، سمت خودمون throttle و batch میشه.
Java، Paper API — الگویی قابلانتقال
یک لایه تشخیص رفتاری که اصالتاً برای یک سرور ماینکرفت (Paper API) ساخته شد، طراحیشده برای گرفتن الگوهای غیرعادی حرکت، نشونهروی و نبرد از نظر آماری، بدون نیاز به نصب هیچ مود سمت کلاینتی — کل موتور سمت سرور اجرا میشه، پس چیزی برای مهندسی معکوس یا دور زدن توسط سازنده تقلب روی کلاینت وجود نداره. محدودیت سخت، کارایی بود: منطق تشخیص داخل tick loop خود سرور اجرا میشه، پس هر چک تا حد میکروثانیه پروفایل و بهینه شد تا هیچ لگ محسوسی برای هزاران بازیکن واقعی اطراف اون یک نفر تحت نظر اضافه نکنه. الگوی زیربنایی — تشخیص ناهنجاری آماری داخل یک حلقه بلادرنگ فشرده — مخصوص ماینکرفت نیست؛ همین معماری برای تشخیص تقلب توی هر سیستم زندهای که «یه چیزی درست نیست» باید در حد میلیثانیه گرفته بشه (نه یک روز بعد توی یک لاگ) قابلاستفادهست.
Go، PostgreSQL RLS
بکاندی که چند سازمان مشتری جدا رو از یک دیپلوی مشترک سرویس میده، با Row-Level Security پستگرس که جداسازی داده رو مستقیم در سطح دیتابیس اجرا میکنه — نه فقط توی کد اپلیکیشن که یک باگ آینده میتونه دورش بزنه. حتی یک سرور اپلیکیشن کاملاً هکشده یا بدتنظیم هم نمیتونه داده یک مشتری رو به مشتری دیگه لو بده، چون دیتابیس خودش قبل از اجرا شدن کوئری رو رد میکنه، مهم نیست کد اپلیکیشن چی درخواست کرده باشه. مخصوصاً با Go ساخته شده چون goroutine های سبکش اجازه میده یک دیپلوی بهراحتی هزاران اتصال همزمان بهازای هر مستاجر رو نگه داره، بدون overhead حافظهای که یک مدل thread-per-request توی همون مقیاس میداشت.
Go، Redis
یک سرویس دروازه که جلوی مجموعهای از API های بکاند میشینه، ساختهشده برای جذب ترافیک ناگهانی و پرحجم بدون اینکه هیچوقت یک جهش ترافیکی سرویسهای پشتش رو از پا دربیاره. rate limiting توزیعشده و کش پاسخ توی Redis زندگی میکنن، مشترک بین تمام instance های دروازه، پس محدودیت مهم نیست درخواست به کدوم instance بخوره، یکسان اعمال میشه. عمداً حول تخریب برازنده (graceful degradation) طراحی شده: یک جهش ناگهانی ۱۰ برابری ترافیک لبه سیستم throttle و صفبندی میشه، پس بکاند یک منحنی نرم و قابلجذب میبینه، نه یک دیوار — تفاوت بین یک پاسخ کند و یک قطعی کامل.
// Client work previews are demoed live, not shipped as
// downloadable source — ask us for a walkthrough.