Olaylar ve Zaman Damgaları: Bir şey gerçekte ne zaman oldu?

kapanış bildirimi

Bu makale İngilizce olarak da mevcuttur. Teknik yardımla tercüme edildi ve yayınlanmadan önce editoryal olarak gözden geçirildi.

Bir daha gösterme.

Olaylarla çalışan herkes er ya da geç görünüşte basit bir soruyla karşılaşır: Bir şey gerçekte ne zaman oldu? Cevap açık görünüyor çünkü her olaya bir zaman damgası eşlik ediyor. CloudEvents'te buna benzer bir şey time-Bir olay kaydedildiğinde birçok sistemin otomatik olarak ayarlandığı alan. Bu zaman damgasını iş mantığı için kullanmak mantıklıdır, sonuçta oradadır. Ancak ince hatalara ve yanlış varsayımlara yol açan şey tam olarak budur.

Sorun şu: Kitap ne zaman ödünç alındı?

Klasik bir kütüphane örneğini ele alalım. Bir okuyucu bir kitabı ödünç alır ve sistem aşağıdaki olayı oluşturur:

{
"source": "https://library.thenativeweb.io",
"subject": "/books/42",
"type": "io.thenativeweb.library.book-borrowed",
"data": {
"borrowedBy": "/readers/23",
"borrowedUntil": "2026-02-12"
}
}

Bir şey fark ettin mi? Etkinlik şunları içerir: borrowedUntil (dönüş tarihi), ancak hayır borrowedAt. Kitabın gerçekten ne zaman ödünç alındığını bilmek istiyorsanız etkinliğin teknik zaman damgasını kullanmalısınız.

Ancak sorun şu: Ya okuyucu kitabı saat 14:00'te teslim aldıysa ancak sistem olayı saat 14:02'ye kadar yazmadıysa? Ya da kütüphaneci dünün kredilerini bu sabah girmiş olsaydı? Teknik zaman damgası bize ödünç almanın gerçekte ne zaman gerçekleştiğini değil, etkinliğin ne zaman kaydedildiğini gösterir.

Çünkü teknik zaman damgaları iş zaman damgaları değildir

Teknik zaman damgalarının iş mantığı açısından sorunlu olmasının birkaç nedeni vardır. Teknik zaman damgası sistemin bir şeyi ne zaman yaptığını açıklar. İş zaman damgası, gerçek dünyada bir şeyin ne zaman gerçekleştiğini tanımlar. Bunlar temelde farklı iki kavramdır ve bunların karıştırılması ince hatalara yol açabilir.

THE time-Bir etkinlik alanı şu soruyu yanıtlar:

“Bu olay ne zaman kaydedildi?”

Ancak teknik gereklilik genellikle şu şekildedir:

“Bu gerçekten ne zaman oldu?”

Bu aynı soru değil. Ve önemli: Bu bir kesinlik veya gecikme meselesi değil, daha çok bir anlambilim meselesi.

Ayrıca, zaman damgası alanının mevcut olup olmaması, etkinliğin biçimine bağlıdır. CloudEvents'te bir tane var timealanı, ancak diğer formatlar olmayabilir. Olayları farklı bir formata dönüştürmeniz gerekirse (örneğin arşivlemek, dışa aktarmak veya diğer sistemlere entegre etmek için), teknik zaman damgasını kaybetme riskiyle karşı karşıya kalırsınız. İş mantığınız göçle yok olabilecek bir sektöre bağlıysa, sallantılı bir zemin üzerine inşa ediyorsunuz.

Ve belki de en güçlü argüman: olaylar genellikle yalnızca gerçek olaydan sonra kaydedilir. Bazı örnekler:

• Bir kütüphaneci, birisinin dünkü krediyi yanlış tarihle kaydettirdiğini fark eder. Dün olan bir şeye atıfta bulunsa bile düzeltme olayını bugün yazın.
• Bir mobil kütüphane uygulaması, cihaz çevrimdışıyken ödünç alınan bir şeyi kaydeder. Saatler sonra senkronize ederseniz etkinlik yalnızca o saatte gerçekleştirilecektir ancak asıl ödünç alma işlemi çok daha önce gerçekleşmiştir.
• Eski bir sistemden veri taşımak, yıllar süren tarihsel olayları içe aktarır. Teknik zaman damgalarının tümü bugünün tarihini göstererek tarihsel analizi işe yaramaz hale getirir.
• Hedef sistem geçici olarak kullanılamıyorsa olaylar önbelleğe alınıp daha sonra yazılabilir. Teknik zaman damgası orijinal olayı değil, yazının yazıldığı zamanı gösterir.

Tüm bu durumlarda teknik zaman damgası iş mantığı açısından yanlış yanıtlar sağlar.

Çözüm: Zamanı açıkça belirtin

Bu şu anlama gelir: Eğer saat şirketle ilgiliyse olay verisine aittir. İşte ödünç alma olayının geliştirilmiş versiyonu:

{
"source": "https://library.thenativeweb.io",
"subject": "/books/42",
"type": "io.thenativeweb.library.book-borrowed",
"data": {
"borrowedBy": "/readers/23",
"borrowedAt": "2026-01-12T14:00:00.000Z",
"borrowedUntil": "2026-02-12"
}
}

Artık anlambilim açık:

• borrowedAt: Kitabın ödünç alındığı tarih (açılış saati)
• borrowedUntil: Kitabın ne zaman iade edilmesi gerektiği (çalışma saatleri (zaten doğruydu))
• Olay zaman damgası: sistemin bu olayı kaydettiği zaman (teknik zaman)

İlginç olan şu borrowedUntil zaten çalışma zamanı olan bir alandı. Eksik olan tek şey karşılığıydı borrowedAt. Bu tutarsızlık tipiktir: geliştiriciler genellikle gelecekteki zaman noktalarını (son teslim tarihleri, son tarihler, son kullanma tarihleri…) dahil etmeyi düşünürler, ancak geçmiş zaman noktalarını, yani bir şeyin gerçekte ne zaman gerçekleştiğini unutma eğilimindedirler.

Daha fazla örnek

Şablon diğer etkinliklere aktarılabilir:

• book-borrowed ile borrowedAt: Kitabın ödünç alındığı zaman
• book-returned ile returnedAt: Kitap iade edildiğinde
• reader-registered ile registeredAt: Oyuncu oturum açtığında
• late-fee-charged ile chargedFor: Tarifenin kapsadığı süre

Bu alanların her biri, sistemin bunu ne zaman kaydettiğine bakılmaksızın, gerçek dünyada bir şeyin ne zaman gerçekleştiğini tanımlar.

Teknik zaman damgası kabul edilebilir olduğunda

Bu, teknik zaman damgasını tamamen göz ardı etmeniz gerektiği anlamına mı geliyor? Hayır. Meşru kullanımlar vardır: olayların kalıcılık sırasını anlamak için hata ayıklama. Sistem gecikmesini ve verimini ölçmek için izleme. Kayıtların sisteme ne zaman girdiğini belgelemek için denetim izleri.

Ancak bunların hepsi teknik konular, profesyonel konular değil.

Peki iş zamanı alanı eklemeyi unutursanız geri dönüş olarak teknik zaman damgasına ne dersiniz? Bu bir çözüm değil, geçici bir çözümdür. Bu durumdaki herkes, etkinlik türünün açık zaman alanını içeren yeni bir sürümünü sunmayı düşünmelidir. Evet, o zaman her iki versiyonu da işleyebilmeniz, ancak gelecek için netlik ve doğruluk elde etmeniz gerekir.

Her şeyi yapmaya bile çalışmamalısın

“gecikme oldukça küçük”

VEYA

“Yüksek hassasiyete ihtiyacımız yok”

üzerinden uçmak. Bu argümanlar asıl noktayı kaçırıyor. Bu bir gecikme veya kesinlik meselesi değil, anlamsal netlik meselesidir. Teknik zaman damgası ve iş zaman damgası, değerleri ne kadar yakın olursa olsun farklı soruları yanıtlar.

Çözüm

Yakından bakana kadar zaman basit görünür. Olaylarla çalışırken “bir şeyin ne zaman olduğu” ile “sistemin bunu ne zaman kaydettiği” arasındaki ayrım kritik öneme sahiptir. Bu çizgiyi bulanıklaştıran herkes sinsi hatalar, hatalı raporlama ve gerçeği tam olarak yansıtmayan sistemler riskiyle karşı karşıya kalır.

Çözüm basit: Eğer zaman işle alakalıysa, açıkça olay verisine aittir. Gelecekteki benliğiniz (ve bu olayları daha sonra analiz etmek zorunda olan herkes) size teşekkür edecektir.

(DSÖ)