About Garnish
Garnish is based in New York and Cairo and builds the complete growth and ordering stack for independent restaurants. On the ordering side: customer website, staff admin, in-store POS, and mobile app, backed by Postgres, Stripe Connect for payments, a pos integration for menus and tickets, and a courier API for delivery.
The role
Please Don't apply if you have less than 4 years of work experience. This is a greenfield backend role. You'll design and build our multi-tenant platform backend from the ground up while existing client deployments keep serving live traffic, which means the new system has to be provably correct before anything migrates onto it, and migration has to be reversible.
You'll make the foundational calls: the tenancy model, the service boundaries, how money and menu state stay consistent with third parties we don't control, and what our release pipeline guarantees before a change reaches a restaurant that's mid-service.
Architecture you'll design
- Tenancy model. Shared schema with row-level security, schema-per-tenant, or database-per-tenant, with a defensible argument for the choice and a migration path if it turns out wrong. Tenant isolation is a security boundary here, not a convenience.
- Consistency with systems we don't own. Menus originate in a POS, payments settle asynchronously, couriers report by webhook. You'll design the reconciliation that proves our state matches theirs, rather than assuming a successful API call meant anything.
- Idempotency and delivery semantics. Webhook deduplication, idempotency keys, the transactional outbox, at-least-once processing with effectively-once outcomes. Every integration path can be retried, and several will be.
- Job execution. Durable queues, visibility timeouts, poison-message handling, backpressure, and scheduled reconciliation. Some work genuinely doesn't fit in a request or a function timeout.
- Data model and schema evolution. Expand/contract migrations, zero-downtime column changes, backfills that can be paused, and constraints that make bad states unrepresentable rather than merely discouraged.
- API contracts. Typed end-to-end, versioned deliberately, with the blast radius of a breaking change understood before it ships.
CI/CD and release engineering
This matters more here than in most backend roles, and we'd want your opinion on it early. Our customers are restaurants: a bad deploy during service means staff can't see orders that are still arriving.
- Per-branch preview environments, and a pipeline where a change is exercised against realistic data before it reaches production
- Migration gating, schema changes ordered, verified and reversible across many databases with independent histories, and never applied implicitly by a deploy
- Staged and scheduled rollouts, with deployment windows that respect a restaurant's service hours
- Fast, boring rollback, measured in seconds, and rehearsed rather than assumed
- Automated checks that encode past incidents: contract tests against integration payloads, smoke tests on the paths that move money, and build-time guards that fail on a whole class of mistake rather than one instance
- Secret and environment management across many deployments, without the same value being pasted by hand into each
What we're looking for
- Postgres, deeply. Row-level security, index and query-plan work, connection pooling, and zero-downtime migrations against live data
- Payments. You've built on Stripe Connect or equivalent, marketplace splits, destination charges, application fees, reversals, webhook signature verification, and strict separation of test and live credentials
- Distributed correctness. You reach for idempotency keys, outboxes, and reconciliation jobs by instinct, and you can explain why exactly-once delivery isn't a thing you can buy
- CI/CD ownership. You've built pipelines, not just used them, including the migration and rollback story
- TypeScript and Node in production. We're a Next.js shop; you don't need to love the frontend, but you'll read it
- You write down why. Our code explains which failure produced which guard, and we'd expect yours to
- Comfortable being the person who says a deploy waits until the restaurant closes
Must have
- Based in Greater Cairo, Egypt
- English Fluency
- 4+ Years of work experience
Nice to have
- Startup experience highly encouraged.
- Graduates of AUC, GUC, Cairo University, and Ain Shams University are highly encouraged to apply.
- Previous POS or F&B (food & beverage) industry experience highly encouraged
عن Garnish
يقع مقر Garnish في نيويورك والقاهرة، وتقدم منظومة كاملة للنمو والطلبات للمطاعم المستقلة. من جانب الطلبات: موقع إلكتروني للعملاء، ولوحة تحكم للموظفين، ونظام نقاط البيع (POS) داخل المتجر، وتطبيق للهاتف المحمول، مدعومة بنظام Postgres، وStripe Connect للمدفوعات، وتكامل مع نقاط البيع للقوائم والتذاكر، وواجهة برمجية (API) لخدمات التوصيل.
الدور الوظيفي
يُرجى عدم التقدم إذا كانت لديك خبرة عمل أقل من 4 سنوات. هذا دور جديد تمامًا للأنظمة الخلفية (greenfield backend). ستعمل على تصميم وبناء النظام الخلفي لمنصتنا متعددة المستأجرين (multi-tenant) من الصفر، بينما تستمر تطبيقات العملاء الحالية في خدمة جميع عمليات الحركة المباشرة، مما يعني أن النظام الجديد يجب أن يكون دقيقًا ومصادقًا على صحته تمامًا قبل نقل أي شيء إليه، كما يجب أن تكون عملية النقل قابلة للعكس.
ستتخذ القرارات التأسيسية: نموذج التأجير/تعدد المستأجرين (tenancy model)، وحدود الخدمات، وكيفية الحفاظ على اتساق المعاملات المالية وحالة القوائم مع الأطراف الخارجية التي لا نتحكم بها، وما يضمنه خط أنابيب الإصدارات الخاص بنا قبل أن يصل أي تغيير إلى مطعم أثناء وقت الخدمة المباشرة.
الهندسية المعمارية التي ستصممها
- نموذج التأجير/تعدد المستأجرين (Tenancy model). مخطط مشترك (Shared schema) مع أمان على مستوى الصفوف (row-level security)، أو مخطط لكل مستأجر (schema-per-tenant)، أو قاعدة بيانات لكل مستأجر (database-per-tenant)، مع حجج قوية تدعم هذا الخيار ومسار نقل في حال تبين أنه غير مناسب. إن عزْل المستأجرين يُعد خط حماية أمنيًا هنا وليس مجرد ميزة للراحة.
- الاتساق مع الأنظمة التي لا نملكها. تنشأ القوائم في نظام نقاط البيع (POS)، وتتم تسوية المدفوعات بشكل غير متزامن، ويقوم مندوبو التوصيل بالإبلاغ عبر Webhook. ستصمم عملية التسوية (reconciliation) التي تثبت أن حالتنا تتوافق مع حالتهم، بدلاً من افتراض أن نجاح استدعاء API يعني أن كل شيء تم بنجاح.
- التكرارية ودلالات التسليم (Idempotency and delivery semantics). إزالة تكرار Webhook، ومفاتيح التكرارية (idempotency keys)، وصندوق الصادر للعمليات (transactional outbox)، والمعالجة لمرة واحدة على الأقل بنتائج فعالة لمرة واحدة فقط. يمكن إعادة محاولة كل مسار تكامل، وسيتم تكرار عدة مسارات بالفعل.
- تنفيذ المهام (Job execution). طوابار الانتظار الدائمة (Durable queues)، وفترات إخفاء الرسائل (visibility timeouts)، ومعالجة الرسائل الضارة (poison-message)، والضغط العكسي (backpressure)، والتسوية المجدولة. بعض المهام لا تتناسب بالفعل مع مهلة الطلب أو المهلة الزمنية للوظيفة.
- نموذج البيانات وتطور المخطط. عمليات النقل بالتوسيع/التقليص (Expand/contract migrations)، وتغييرات الأعمدة دون توقف النظام (zero-downtime)، والتعبئة الخلفية التي يمكن إيقافها مؤقتًا، والقيود التي تجعل الحالات السيئة مستحيلة التمثل بدلاً من مجرد عدم التوصية بها.
- عقود واجهات البرمجة (API contracts). محددة الأنواع بالكامل، ومؤرخة بالإصدارات بعناية، مع فهم مدى تأثير أي تغيير جوهري قبل إطلاقه.
هندسة التكامل والتسليم المستمر (CI/CD) والإصدارات
هذا الأمر يكتسب أهمية أكبر هنا مقارنة بمعظم أدواري الأنظمة الخلفية الأخرى، ونود معرفة رأيك في هذا المجال مبكرًا. عملاؤنا هم مطاعم: ونشر كود يتضمن أخطاء أثناء وقت الخدمة يعني أن الموظفين لن يستطيعوا رؤية الطلبات الواردة.
- بيئات معاينة لكل فرع (Per-branch preview environments)، وخط أنابيب يتم فيه اختبار التغييرات مقابل بيانات واقعية قبل وصولها إلى بيئة الإنتاج الفعلية
- بوابات النقل (Migration gating)، تغييرات المخطط مرتبة ومتحقق منها وقابلة للعكس عبر قواعد بيانات متعددة ذات سجلات مستقلة، ولن تـُطبق أبدًا بشكل ضمني عن طريق عملية النشر
- عمليات إطلاق مرحلية ومجدولة، مع فترات زمنية للنشر تراعي ساعات الخدمة الخاصة بالمطعم
- التراجع السريع والسلس (rollback) يُقاس بالثواني، ومُجرب ومُدرَّب عليه بدلاً من الافتراض
- فحوصات مؤتمتة تسجل الحوادث السابقة: اختبارات العقد مقابل حمولات التكامل، واختبارات الدخان (smoke tests) على المسارات التي تحول الأموال، وحمايات وقت البناء التي تكتشف فئة كاملة من الأخطاء بدلاً من حالة واحدة فقط
- إدارة الأسرار والبيئات عبر عمليات نشر متعددة، دون الحاجة للنسخ واللصق اليدوي لنفس القيم في كل منها
ما نبحث عنه
- خبرة عميقة في Postgres. الأمان على مستوى الصفوف (Row-level security)، والعمل على الفهارس وخطط الاستعلام (query-plan)، وتجميع الاتصالات (connection pooling)، وعمليات النقل بدون توقف النظام مع البيانات المباشرة
- المدفوعات. خبرة في البناء باستخدام Stripe Connect أو ما يعادله، وتقسيم المبيعات للمتاجر متعددة البائعين (marketplace splits)، والرسوم المباشرة (destination charges)، ورسوم التطبيق، والاسترداد، والتحقق من توقيع Webhook، والفصل التام بين بيانات الاعتماد للاختبار والبيانات المباشرة
- الدقة والموثوقية في الأنظمة الموزعة. الاستخدام التلقائي لمفاتيح التكرارية (idempotency keys)، وصناديق الصادر (outboxes)، ومهمات التسوية (reconciliation)، والقدرة على شرح سبب عدم إمكانية "التسليم لمرة واحدة بالضبط" (exactly-once delivery) كحل جاهز يمكن شراؤه
- ملكية خطوط CI/CD. قمت ببناء خطوط الأنابيب بنفسك، ولم تكتفِ باستخدامه، بما في ذلك سيناريوهات النقل والتراجع (rollback)
- خبرة عمل بـ TypeScript وNode في بيئات الإنتاج. نحن نعتمد على Next.js؛ لست بحاجة لإتقان الواجهة الأمامية تمامًا، ولكن ستكون قادرًا على قراءتها وفهمها
- توثق الأسباب. توضح أكوادنا البرمجية أي خطأ أدى إلى بناء أي حماية، ونتوقع منك الشيء نفسه
- أن تكون مرتاحًا لكونك الشخص الذي يقرر تأجيل عملية النشر حتى يغلق المطعم أبوابه
المتطلبات الأساسية
- إقامة في القاهرة الكبرى، مصر
- إتقان اللغة الإنجليزية
- خبرة عمل تزيد عن 4 سنوات
المتطلبات المفضلة
- يُفضل بقوة من لديه خبرة في الشركات الناشئة (Startups).
- يُشجع خريجو الجامعة الأمريكية بالقاهرة، والجامعة ألمانية بالقاهرة، وجامعة القاهرة، وجامعة عين شمس بشدة على التقدم.
- يُفضل بقوة من لديه خبرة سابقة في مجال نقاط البيع (POS) أو قطاع الأغذية والمشروبات (F&B)