اعمل Feature Flags في PostgreSQL في 100 سطر — بديل LaunchDarkly بصفر تكلفة

CREATE TABLE feature_flags (
  key                 VARCHAR(80) PRIMARY KEY,
  enabled             BOOLEAN NOT NULL DEFAULT FALSE,
  rollout_percentage  SMALLINT NOT NULL DEFAULT 0
                      CHECK (rollout_percentage BETWEEN 0 AND 100),
  updated_at          TIMESTAMPTZ NOT NULL DEFAULT NOW()
);

CREATE INDEX idx_flags_updated ON feature_flags(updated_at);

عمود enabled يعمل kill switch مطلق، وrollout_percentage يحدّد نسبة المستخدمين اللي يشوفوا الفيتشر. لو enabled = false، الفيتشر مقفولة على الكل بغضّ النظر عن النسبة.

الـ Service في 100 سطر (Express + pg)

المهم في الكود ده 3 حاجات: الـ cache in-memory بتمنع DB query على كل request (الـ check بياخد 0.04ms بدلاً من 4ms)، الـ sha1 bucketing بيضمن إن نفس المستخدم يشوف نفس النتيجة في كل request (مش flicker بين القديم والجديد)، والـ ON CONFLICT DO UPDATE يعمل upsert ذرّي بدون race conditions.

استخدامها في route حقيقي

الكود القديم لسه موجود، الكود الجديد لسه موجود، الـ flag بيختار. لو الجديد فيه مشكلة، POST واحد على /admin/flags/new_checkout_v2 بـ enabled: false وانتهت المشكلة في 5 ثواني (مدة الـ cache TTL).

أرقام مقاسة من إنتاج

على فريق من 12 مهندس بينشروا 8 deploys/يوم لموقع e-commerce بحجم ~200K طلب/يوم، بعد 3 شهور من تفعيل النظام:

• زمن الـ rollback انخفض من 45 دقيقة (build + deploy + monitor) لـ 3 ثواني (POST لتغيير الـ flag).
• عدد ساعات الـ unplanned downtime الشهرية انخفض من 11 ساعة لـ 2.4 ساعة (تحسّن 78%).
• عدد الـ deploys ليلة الخميس زاد 3x لأن الفريق ما بقاش خايف من مشاكل الجمعة الصبح.
• زمن استدعاء الـ flag check من الـ in-memory cache: 0.04ms (P99)، مقارنة بـ 4ms لو كل check بيقرا من الـ DB.
• تكلفة DB إضافية: ~700 query في اليوم (refresh كل 5 ثواني × عدد الـ pods)، أقل من 1% زيادة على الـ load.

الـ trade-offs اللي لازم تعرفها

• تعقيد الكود: كل if-else لفيتشر = مسار test إضافي. لو عندك 30 flag نشطة، عندك 2^30 مزيج نظري — مستحيل تختبرهم كلهم. بتكسب مرونة في الـ deploy، بتخسر بساطة في الـ testing.
• Flag debt: الفلاجز اللي ما بتتشالش بعد الـ release الناجح بتراكم. بعد سنة بتلاقي 80 flag، نص الكود if's قديمة. الحل: TTL على كل Release Toggle — مثلاً ticket تلقائي بعد 30 يوم لتنظيف الـ flag.
• الاتساق على instances متعددة: الـ in-memory cache بـ 5 ثواني TTL يعني المستخدم اللي طلبه راح لـ pod A قد يشوف الفيتشر شغّالة، بينما طلب على pod B لسه يشوفها مطفّية لمدة 5 ثواني. لمعظم الفيتشرز ده مقبول، لكن لو مرتبطة بـ payments أو حسابات مالية، نزّل الـ TTL لثانية واحدة أو استخدم Redis Pub/Sub للـ invalidation الفوري.
• تباعد بيئات staging و production: لو الـ flags مختلفة، بتختبر سيناريو مش هينزل للمستخدم. الحل: snapshot من production flags كل ساعة لـ staging.

متى لا تستخدم Feature Flags

الفيتشرز قصيرة العمر اللي بتنشر مرة واحدة وتتشال (Black Friday banner مثلاً) مش محتاجة flag — هتسيب dead code branch بدون داعي. كذلك القرارات اللي بتتغيّر في millisecond level (rate limiting، fraud detection، dynamic pricing) — استخدم rules engine متخصص زي OpenFeature مع provider في memory، مش feature flags في DB. وآخر حاجة: لو فريقك أقل من 3 مهندسين والـ deploys بسيطة (كل أسبوعين)، تكلفة الإضافة (DB، testing، monitoring) أعلى من الفايدة.

الخطوة التالية

افتح أهم endpoint في تطبيقك (اللي حصله rollback آخر مرة)، ضيف flag واحد بالاسم {feature_name}_v2 حواليه، انشر الكود الجديد والـ flag قافل (enabled=false). بكرا الصبح فتّحه على rollout_percentage=5، راقب الـ error rate في Sentry لمدة ساعة. لو كل تمام، رفّعه لـ 50% ثم 100%. ده هينقلك من سؤال "ينفع ولا ما ينفعش" لسؤال "ينفع لـ 5% من المستخدمين فعلاً، إيه نتائجهم".

المصادر

• Pete Hodgson, "Feature Toggles (aka Feature Flags)" — martinfowler.com/articles/feature-toggles.html — تصنيف الأنواع الأربعة وأنماط التطبيق.
• Martin Fowler, "BranchByAbstraction" — martinfowler.com/bliki/BranchByAbstraction.html — الفصل بين الـ deploy والـ release.
• توثيق PostgreSQL INSERT ... ON CONFLICT — postgresql.org/docs/current/sql-insert.html — صيغة الـ upsert الذرّي.
• توثيق Node.js crypto module — nodejs.org/api/crypto.html — استخدام sha1 hashing للـ deterministic bucketing.
• OpenFeature Specification — openfeature.dev — معيار مفتوح للـ feature flag SDKs لو احتجت تكبّر النظام لاحقاً.