Dağıtık iş zamanlayıcı (job scheduler)

Problem

"Şirketin servislerinin ortak kullanacağı dağıtık bir iş zamanlayıcı tasarla. İki tür iş var: tek seferlik gecikmeli işler ('ödenmeyen siparişi 30 dakika sonra iptal et', 'yarın 18:00'de hatırlatma gönder') ve tekrarlayan cron işleri ('her gece 02:00'de rapor üret'). İşler zamanında başlamalı, worker çökerse kaybolmamalı ve aynı iş iki kez çalışıp zarar vermemeli."

Bu soru, dağıtık sistemlerin en temel üç kavramını tek bir üründe birleştirir: kiralama (lease) ile iş sahipliği, en az bir kez çalıştırma ve idempotent işler, ve lider seçimi. Mülakatçı adayın "tam bir kez çalıştırma" iddiasına düşüp düşmediğine, iş sahipliğinin zamanla dolan bir kira olarak modellenip modellenmediğine, gece yarısı gibi yuvarlak saatlerdeki yığılmaya ve worker'ın "öldü sanılıp aslında yaşadığı" (zombi) senaryosuna bakar.

Netleştirme soruları ve varsayımlar

Kapasite tahmini

İş sayısı           : 10M /gün ≈ 116 /s ortalama
Yuvarlak saat dalgası: 00:00 ve 09:00'da 1M iş; bir dakika içinde başlaması gerekirse
                       1.000.000 / 60 ≈ 16.700 iş/s
Bekleyen iş         : aylar sonrasına zamanlanmış dahil ~50M satır
İş kaydı            : ~1 KB (payload, durum, deneme bilgisi)
Depolama            : 10M x 1 KB = 10 GB/gün; 30 gün geçmiş ≈ 300 GB + bekleyenler ~50 GB

Teşhis:

• Ortalama hız küçük (saniyede yüzün biraz üstü); tek bir PostgreSQL kümesi bunu rahat kaldırır.
• Asıl yük yuvarlak saatlerde yığılır: gece yarısı 1 milyon işin bir dakika içinde başlatılması bile ortalamanın ~140 katı bir dalga demektir (aynı saniyeye yığılırsa binlerce katı). Bu dalga hem zamanlayıcıyı hem de işlerin çağırdığı servisleri ezer. Tasarımın önemli bir kısmı bu yığılmayı yaymakla ilgilidir.
• Doğruluk problemi, ölçekten büyüktür: worker çökmesi, ağ bölünmesi ve GC duraklaması altında bir işin kaybolmaması ve iki kez zarar vermemesi.

API

POST /api/v1/jobs
Idempotency-Key: order-98213-auto-cancel
{ "type": "ORDER_AUTO_CANCEL",
  "runAt": "2026-10-23T14:30:00Z",
  "target": { "kind": "KAFKA", "topic": "order-commands", "key": "98213" },
  "payload": { "orderId": 98213 },
  "maxAttempts": 5, "timeoutSeconds": 60 }
-> 201 { "jobId": "job_01H...", "status": "SCHEDULED" }

POST /api/v1/cron-jobs
{ "name": "daily-settlement-report", "schedule": "0 2 * * *", "timeZone": "Europe/Istanbul",
  "target": { "kind": "HTTP", "url": "https://reports.internal/run" },
  "misfirePolicy": "RUN_ONCE", "concurrency": "FORBID", "jitterSeconds": 300 }

PATCH  /api/v1/jobs/{jobId}       { "runAt": "..." }     # sadece SCHEDULED iken
DELETE /api/v1/jobs/{jobId}                               # iptal, sadece başlamamışsa
GET    /api/v1/jobs/{jobId}                               # durum, deneme geçmişi

• Idempotency key iş oluşturmayı tekrarlara karşı korur: sipariş servisi "30 dakika sonra iptal et" işini iki kez kaydetmemeli.
• Hedef, işin iş mantığını değil, tetiklenecek yeri tanımlar. Zamanlayıcı genel amaçlıdır; "siparişi iptal etmek" sipariş servisinin işidir.
• concurrency: FORBID, bir önceki çalışma bitmeden yenisinin başlamamasını ister (Kubernetes CronJob'daki concurrencyPolicy ile aynı fikir).

Veri modeli

CREATE TABLE jobs (
    id              UUID        PRIMARY KEY,
    idempotency_key VARCHAR(200) NOT NULL,
    owner_service   VARCHAR(64)  NOT NULL,
    type            VARCHAR(64)  NOT NULL,
    cron_id         UUID,                         -- tekrarlayan işin bir çalışmasıysa
    scheduled_for   TIMESTAMPTZ NOT NULL,         -- mantıksal zaman (cron'un planladığı an)
    run_at          TIMESTAMPTZ NOT NULL,         -- jitter ve retry sonrası gerçek çalışma zamanı
    status          VARCHAR(16) NOT NULL,         -- SCHEDULED, RUNNING, SUCCEEDED, FAILED, CANCELLED
    attempt         INT         NOT NULL DEFAULT 0,   -- her sahiplenmede artar (fencing token)
    max_attempts    INT         NOT NULL,
    locked_by       VARCHAR(128),
    lease_until     TIMESTAMPTZ,
    target          JSONB       NOT NULL,
    payload         JSONB       NOT NULL,
    last_error      TEXT,
    created_at      TIMESTAMPTZ NOT NULL DEFAULT now(),
    CONSTRAINT jobs_idem_uq UNIQUE (owner_service, idempotency_key),
    CONSTRAINT jobs_cron_once_uq UNIQUE (cron_id, scheduled_for)
);

CREATE INDEX jobs_due_idx     ON jobs (run_at)      WHERE status = 'SCHEDULED';
CREATE INDEX jobs_lease_idx   ON jobs (lease_until) WHERE status = 'RUNNING';

CREATE TABLE cron_jobs (
    id              UUID PRIMARY KEY,
    name            VARCHAR(128) NOT NULL UNIQUE,
    schedule        VARCHAR(64)  NOT NULL,
    time_zone       VARCHAR(64)  NOT NULL,
    next_fire_at    TIMESTAMPTZ  NOT NULL,
    misfire_policy  VARCHAR(16)  NOT NULL,
    concurrency     VARCHAR(16)  NOT NULL,
    jitter_seconds  INT          NOT NULL DEFAULT 0,
    enabled         BOOLEAN      NOT NULL DEFAULT true
);

• Partial index'ler (WHERE status = 'SCHEDULED') sorguyu bekleyen işlerle sınırlar; tamamlanmış milyonlarca satır index'i şişirmez.
• UNIQUE (cron_id, scheduled_for), bir cron'un aynı mantıksal zaman için iki kez çalışma üretmesini veritabanı seviyesinde imkansız kılar. Bu, lider seçimindeki hataların zararsız kalmasını sağlayan kilit constraint'tir.
• Tamamlanmış işler günlük partition'lara taşınır ve 30 gün sonra partition düşürülerek silinir.

Yüksek seviye tasarım

flowchart LR
    SVC[İstemci servisler] -->|iş oluştur| API[Zamanlayıcı API]
    API --> DB[(PostgreSQL jobs ve cron_jobs)]
    CM[Cron materializer, tek lider] --> DB
    W1[Worker 1] -->|SKIP LOCKED ile sahiplen| DB
    W2[Worker 2] -->|SKIP LOCKED ile sahiplen| DB
    W3[Worker N] -->|SKIP LOCKED ile sahiplen| DB
    W1 -->|tetikle| K[(Kafka komut topic'leri)]
    W2 -->|tetikle| HTTP[Hedef servis HTTP uç noktaları]
    K --> TGT[Hedef servisler, idempotent handler]
    REAP[Lease toplayıcı] --> DB
    LE[Lider seçimi, lease] --> CM

• API işleri kaydeder; idempotency key ile tekrarları eler.
• Worker'lar zamanı gelmiş işleri sahiplenir, hedefe tetikleme gönderir, sonucu yazar. Hepsi eşittir; aralarında koordinasyon veritabanı satır kilitleri üzerinden olur.
• Cron materializer tekrarlayan tanımlardan bir sonraki çalışmayı jobs tablosuna yazar. Tek bir lider olarak çalışır ama tasarım iki liderin aynı anda çalışmasına da dayanıklıdır.
• Lease toplayıcı süresi dolmuş RUNNING işleri tekrar SCHEDULED yapar (worker'lar bunu sahiplenme sorgusunda da yapabilir).

Derinlemesine

İşi sahiplenmek: SKIP LOCKED ve lease

Birden fazla worker aynı tabloyu tarar; her işin tek bir worker tarafından alınması gerekir. Worker kısa bir transaction'da işi sahiplenir, commit eder ve işi transaction dışında çalıştırır:

-- 1) Sahiplenme (kısa transaction)
WITH due AS (
    SELECT id
      FROM jobs
     WHERE status = 'SCHEDULED' AND run_at <= now()
     ORDER BY run_at
     LIMIT 100
       FOR UPDATE SKIP LOCKED
)
UPDATE jobs j
   SET status = 'RUNNING', attempt = j.attempt + 1,
       locked_by = :workerId, lease_until = now() + interval '2 minutes'
  FROM due
 WHERE j.id = due.id
RETURNING j.id, j.attempt, j.target, j.payload;

-- 2) İş çalıştırılır (transaction dışında, hedefe tetikleme gönderilir)

-- 3) Tamamlama: sadece hâlâ sahibi isek
UPDATE jobs SET status = 'SUCCEEDED', lease_until = NULL
 WHERE id = :id AND status = 'RUNNING' AND attempt = :attempt;

Neden böyle:

• FOR UPDATE SKIP LOCKED: Başka bir worker'ın o an kilitlediği satırlar beklenmeden atlanır; worker'lar birbirini bloklamadan farklı işleri alır. PostgreSQL dokümantasyonu bu seçeneğin tutarsız bir görünüm verdiğini, genel amaçlı sorgular için uygun olmadığını ama kuyruk benzeri tablolarda birden fazla tüketicinin çekişmesini önlemek için kullanılabileceğini söyler; bu tablo tam olarak böyle bir kuyruktur.
• İş transaction dışında çalışır: İşi FOR UPDATE kilidini tutarak çalıştırmak, dakikalarca açık transaction (bağlantı havuzu tükenir, VACUUM engellenir) demektir. Sahiplik kilitle değil, satırdaki durumla tutulur.
• Lease: Sahiplik süresizdir değil, lease_until'e kadardır. Worker çökerse lease dolar ve iş başka bir worker tarafından tekrar alınır. Uzun işler çalışırken periyodik olarak lease'i uzatır (heartbeat): UPDATE jobs SET lease_until = now() + interval '2 minutes' WHERE id = :id AND status = 'RUNNING' AND attempt = :attempt; 0 satır dönerse worker sahipliği kaybetmiştir ve durmalıdır.
• attempt bir fencing token'dır: Her sahiplenmede artar. Tamamlama ve heartbeat attempt = :attempt koşuluyla yapılır. Eski sahip (lease'i dolmuş ama aslında yaşayan bir worker) geç kalmış tamamlamasını yazmaya çalışırsa 0 satır etkiler.

stateDiagram-v2
    [*] --> SCHEDULED
    SCHEDULED --> RUNNING : worker sahiplendi, attempt artar
    RUNNING --> SUCCEEDED : tamamlandı
    RUNNING --> SCHEDULED : lease doldu veya hata, retry zamanı
    RUNNING --> FAILED : deneme hakkı bitti
    SCHEDULED --> CANCELLED : iptal
    SUCCEEDED --> [*]
    FAILED --> [*]
    CANCELLED --> [*]

"Tam bir kez çalıştırma" yoktur: en az bir kez + idempotent iş

Şu senaryo kaçınılmazdır: worker işi tetikler (sipariş servisine "iptal et" komutu gider), sonucu veritabanına yazmadan önce GC duraklamasına girer ya da çöker. Lease dolar, başka bir worker işi tekrar alır ve komut ikinci kez gider. Zamanlayıcı ile hedef servis arasında ortak bir transaction yoktur; bu yüzden zamanlayıcının dürüst garantisi en az bir kez tetiklemedir.

Etkinin bir kez olması hedef tarafta sağlanır:

• Tetikleme, işin kimliğini ve mantıksal zamanını taşır: jobId ve scheduledFor. Hedef servis bunu idempotency anahtarı olarak kullanır (ör. processed_jobs tablosunda unique kayıt, iş verisiyle aynı transaction'da).
• Birçok iş doğal olarak idempotenttir: "sipariş 98213 hâlâ PENDING_PAYMENT ise iptal et" komutu ikinci kez çalıştığında sipariş zaten iptal olduğu için etkisizdir. İşleri "durum X ise Y yap" biçiminde tasarlamak en ucuz idempotency'dir.
• Google SRE kitabının dağıtık cron bölümü de aynı sonuca varır: işlerin ya güvenle tekrar edilebilir ya da durumlarının sorgulanabilir olması gerekir; ve bazı işler için çift çalıştırmak yerine atlamayı tercih etmek daha güvenlidir, çünkü atlanan bir çalışma telafi edilebilir ama çift çalışmanın etkisini geri almak zor ya da imkansız olabilir.

Kubernetes CronJob dokümantasyonu da benzer bir uyarı içerir: CronJob her zamanlama için yaklaşık bir kez Job oluşturur, bazı durumlarda iki Job oluşabilir ya da hiç oluşmayabilir; bu yüzden Job'ların idempotent olması gerekir.

Tekrarlayan işler ve lider seçimi

Cron tanımından bir sonraki çalışmayı üretmek (materialize etmek) basit bir döngüdür: next_fire_at <= now() + 1 dakika olan tanımlar için jobs tablosuna satır ekle ve next_fire_at'i bir sonraki zamana ilerlet. Bunu tek bir sürecin yapması istenir; aksi halde iki süreç aynı çalışmayı iki kez ekler.

Lider seçimi seçenekleri:

Hangisi seçilirse seçilsin, zaman tabanlı bir liderlik iki liderin kısa süre aynı anda çalışmasını tamamen engelleyemez: lider uzun bir GC duraklamasına girer, lease'i dolar, yeni lider seçilir, eski lider uyanır ve bir süre kendini lider sanır (Kitap Bölüm 11'deki Redlock tartışmasının aynısı). Çözüm liderliği doğruluğun dayanağı yapmamaktır: UNIQUE (cron_id, scheduled_for) sayesinde iki lider aynı çalışmayı eklemeye çalışırsa ikincisi ON CONFLICT DO NOTHING ile etkisiz kalır. Liderlik böylece sadece bir verimlilik mekanizmasıdır; doğruluk veritabanı constraint'indedir.

next_fire_at'in ilerletilmesi ve jobs satırının eklenmesi aynı transaction'dadır; materializer çökerse ya ikisi birden olmuştur ya hiçbiri.

Gece yarısı dalgası: thundering herd

Kullanıcılar ve ekipler cron'u yuvarlak saatlere yazar: 0 0 * * *. Bir milyon işin aynı saniyede başlaması hem zamanlayıcıyı hem hedef servisleri ezer. Önlemler:

• Jitter: Tanıma jitterSeconds eklenir; materializer run_at'i scheduled_for + rastgele(0, jitter) olarak yazar. Rastgele yerine deterministik bir sapma daha iyidir: hash(cron_id) % jitter. Her iş her gün aynı saniyede çalışır (öngörülebilir), ama işler arasında yayılır. Google SRE kitabındaki dağıtık cron, crontab'a "herhangi bir değer olabilir" anlamına gelen bir soru işareti uzantısı ekleyip değeri cron yapılandırmasını belirli bir aralığa hash'leyerek seçtiğini anlatır.
• scheduled_for ile run_at ayrımı: Mantıksal zaman (raporun ait olduğu gün) değişmez, sadece fiziksel başlama zamanı kayar. Tekilleştirme ve idempotency mantıksal zamanla yapılır.
• Hedef bazında eşzamanlılık sınırı: Bir hedef servise aynı anda en fazla N tetikleme (worker tarafında hedef başına semafor veya token bucket). Zamanlayıcı, kendi müşterilerini koruyan bir geri basınç noktasıdır.
• Önceden yükleme: Dalgadan bir dakika önce worker'lar zamanı yaklaşan işleri bellekteki bir zamanlama yapısına (zaman çarkı, timing wheel) alıp lease'leyebilir; böylece 00:00:00'da veritabanına 16.000 sorgu/s yerine önceden dağıtılmış küçük sorgular gider.

Kaçırılan çalışmalar, retry ve zaman aşımı

• Misfire politikası: Zamanlayıcı bir saat kapalı kaldıysa saatlik bir cron'un kaçırdığı çalışmalar ne olur? RUN_ALL (her biri çalışır, ör. saatlik faturalama), RUN_ONCE (sadece bir kez telafi, ör. önbellek ısıtma), SKIP (sadece bir sonraki zamanlamayı bekle, ör. "son 5 dakikanın metriklerini gönder"). Varsayılan iş tipine göre seçilir ve tanımda açıkça yazılır.
• Retry: Hedef hata dönerse iş SCHEDULED'a döner, run_at = now() + backoff(attempt) (exponential + jitter). max_attempts dolunca FAILED olur ve sahibi servise olay/alarm gider. Bu, bildirim sistemindeki DLQ'nun karşılığıdır.
• Zaman aşımı: Her işin bir timeoutSeconds'ı vardır; lease süresi bunun üzerinde seçilir. Uzun işler heartbeat ile lease'i uzatır; heartbeat gönderemeyen iş başka worker'a geçebilir, bu yüzden uzun işlerin de idempotent ve tercihen kaldığı yerden devam edebilir (checkpoint) olması gerekir.
• concurrency: FORBID: Bir cron'un önceki çalışması hâlâ RUNNING iken yenisinin sahiplenilmemesi için sahiplenme sorgusuna "aynı cron_id ile çalışan iş yok" koşulu eklenir; Kubernetes CronJob'daki Forbid politikası da önceki çalışma bitmemişse yeni çalışmayı atlar.

Saat dilimi

Cron ifadeleri bir saat dilimine göre yorumlanır ve tanımda IANA adıyla saklanır (Europe/Istanbul). Yaz saati uygulayan bölgelerde ileri alma gecesinde 02:30 hiç yaşanmaz, geri alma gecesinde iki kez yaşanır; her iki durumun davranışı (atla/çalıştır, bir kez/iki kez) tanımlı olmalıdır. Türkiye 2016'dan beri yaz saati uygulamıyor, ama global bir zamanlayıcı bunu tüm bölgeler için çözmek zorundadır. İç saklama UTC'dir (run_at TIMESTAMPTZ), yorum katmanı saat dilimini bilir. Kubernetes CronJob da .spec.timeZone alanıyla IANA saat dilimi kabul eder.

Ölçeklenme

• Tek PostgreSQL kümesiyle başla: Ortalama yük küçük, dalgalar jitter ile yayılır.
• Sorgu maliyeti: Partial index sayesinde sahiplenme sorgusu bekleyen işlerin küçük bir kısmına bakar. Tamamlanmış işler partition'lara taşınır.
• Sharding gerekirse: İşler hash(job_id) % N ile N veritabanına bölünür, her worker grubu bir shard'ı tarar. Shard'lar arası koordinasyon gerekmez, çünkü işler birbirinden bağımsızdır.
• Uzak gelecekteki işler: Aylar sonrasına zamanlanmış işler sıcak tabloda durmak zorunda değildir; "yakın gelecek" tablosu (ör. 24 saat) ve "uzak gelecek" tablosu ayrılabilir, periyodik bir iş uzaktakileri yakına taşır.
• Alternatifler: Redis sorted set ile gecikme kuyruğu (skor = çalışma zamanı) çok hızlıdır ama kalıcılık ve failover garantileri bir iş zamanlayıcının "iş kaybolmamalı" gereksinimine göre zayıftır; Quartz'ın JDBC tabanlı kümelenmiş modu ve ShedLock gibi kütüphaneler aynı veritabanı kilidi fikrini uygulama içinden kullanır; Kubernetes CronJob ise altyapı seviyesindeki periyodik işler için iyidir ama milyonlarca kullanıcı tanımlı işe uygun değildir.

Gözlemlenebilirlik

• Başlama gecikmesi: başlama zamanı - run_at'in p50/p99'u; zamanlayıcının asıl SLI'ı.
• Zamanı gelmiş ama sahiplenilmemiş iş sayısı (birikme), lease dolumu sayısı (worker çökmesi veya yetersiz lease), deneme ve FAILED oranı, hedef bazında hata oranı.
• Cron'lar için "son başarılı çalışma zamanı" alarmı: "günlük mutabakat raporu 26 saattir başarıyla çalışmadı" tipindeki alarm, sessizce duran bir cron'un tek güvenilir tespitidir.

Darboğazlar, hatalar ve trade-off'lar

Trade-off'lar:

• En az bir kez: Kayıp olmaması için tekrarı kabul ettik; tekrarın zararını idempotent işlerle sıfırladık.
• Veritabanı tabanlı kuyruk: Kalıcılık, transaction ve basit işletim; bedeli çok yüksek hızlarda sharding gereksinimi.
• Zaman tabanlı liderlik: Basit; doğruluğu liderliğe değil constraint'e bağlayarak riskini sıfırladık.
• Jitter: Yükü yaydık; bedeli işlerin tam saatinde değil birkaç dakika içinde başlaması.

Üç seviyede cevap

Soru: "Birden fazla worker var. Aynı işin iki worker tarafından alınmasını nasıl engellersin?"

Soru: "Cron işlerini kim tetikler? Lider düşerse ne olur?"

Soru: "Gece 00:00'a zamanlanmış bir milyon iş var. Ne olur, nasıl yönetirsin?"

Mülakatçı için

Takip soruları:

• Bir işin çalışması 3 saat sürüyor ve ortasında worker yeniden başlatılıyor. İşi baştan mı alırsın, kaldığı yerden mi?
• İş zamanlayıcıyı çok bölgeli yapmak istesek ne değişir?
• Kubernetes CronJob ile bu tasarım arasında ne zaman hangisini seçersin?
• Kullanıcıların kendi cron ifadelerini girdiği bir üründe kötü niyetli ya da hatalı ifadelere karşı ne önlem alırsın?

Seviye beklentisi: Mid seviyede SKIP LOCKED, lease, retry ve çok pod'da tekil tetikleme beklenir. Senior'dan fencing token, en az bir kez + idempotency'nin açıkça kurulması, liderliği doğruluktan ayırma, thundering herd yönetimi ve misfire/saat dilimi gibi işletim detayları beklenir.

Hızlı tekrar

Kaynaklar

• Google, Site Reliability Engineering, "Distributed Periodic Scheduling with Cron": Atlamayı çift çalıştırmaya tercih etmek, Paxos tabanlı lider, başlangıç ve bitişin kaydedilmesi, idempotency ve thundering herd için hash tabanlı dağıtım.
• Kubernetes: CronJob: concurrencyPolicy, startingDeadlineSeconds, timeZone, kaçırılan 100 zamanlama kuralı ve Job'ların idempotent olması gerekliliği.
• PostgreSQL: SELECT, The Locking Clause: SKIP LOCKED ve kuyruk benzeri tablolar.
• PostgreSQL: Explicit Locking: Session ve transaction seviyesinde advisory lock'lar.
• Martin Kleppmann, Designing Data-Intensive Applications, Bölüm 8: Lease, süreç duraklamaları ve fencing token'lar.