Milyarlarca k\u0131sa \u00f6m\u00fcrl\u00fc verinin, t\u0131pk\u0131 WhatsApp durumlar\u0131 gibi, her g\u00fcn otomatik olarak silinmesi, devasa \u00f6l\u00e7ekli sistemler i\u00e7in kritik bir operasyondur. Bu s\u00fcre\u00e7, sistem performans\u0131n\u0131 etkilemeden ve kullan\u0131c\u0131 deneyimini bozmadan ger\u00e7ekle\u015fmelidir. Peki, bu b\u00fcy\u00fckl\u00fckteki bir veri ak\u0131\u015f\u0131 nas\u0131l y\u00f6netiliyor ve veritabanlar\u0131 bu a\u011f\u0131r y\u00fck alt\u0131nda nas\u0131l ayakta kal\u0131yor? Bu makalede, bu zorlu\u011fun \u00fcstesinden gelmek i\u00e7in kullan\u0131lan ileri d\u00fczey teknikleri ve mimarileri ad\u0131m ad\u0131m inceleyece\u011fiz.<\/p>\n
B\u00fcy\u00fck \u00f6l\u00e7ekli sistemlerde veri y\u00f6netimi, \u00f6zellikle de k\u0131sa \u00f6m\u00fcrl\u00fc verilerle (ephemeral data) u\u011fra\u015f\u0131rken karma\u015f\u0131k bir hal al\u0131r. WhatsApp durumlar\u0131, Instagram hikayeleri veya Snapchat g\u00f6nderileri gibi veriler, belirli bir s\u00fcre sonra otomatik olarak silinmek \u00fczere tasarlanm\u0131\u015ft\u0131r. Bu t\u00fcr verilerin temel \u00f6zelli\u011fi, genellikle 24 saat gibi k\u0131sa bir ya\u015fam s\u00fcresine sahip olmalar\u0131 ve bu s\u00fcrenin sonunda sistemden temizlenmeleri gerekti\u011fidir. Bu durum, veri depolama ve i\u015fleme mimarilerini geleneksel yakla\u015f\u0131mlardan farkl\u0131 k\u0131lmaktad\u0131r.<\/p>\n
K\u0131sa \u00f6m\u00fcrl\u00fc verilerin y\u00f6netimi, asl\u0131nda iki ana zorlu\u011fu beraberinde getirir: birincisi, bu verilerin milyarlarca adet \u00fcretilmesi ve depolanmas\u0131; ikincisi ise, ayn\u0131 h\u0131zda ve verimlilikle silinmeleri. Geleneksel veritaban\u0131 sistemleri, genellikle uzun \u00f6m\u00fcrl\u00fc, kal\u0131c\u0131 verileri depolamak ve sorgulamak \u00fczere optimize edilmi\u015ftir. Ancak, k\u0131sa \u00f6m\u00fcrl\u00fc verilerin s\u00fcrekli ak\u0131\u015f\u0131 ve ard\u0131ndan otomatik silinme gereklili\u011fi, veritabanlar\u0131 \u00fczerinde benzersiz bir y\u00fck olu\u015fturur. Her g\u00fcn milyarlarca yeni durum olu\u015fturuldu\u011funu ve ayn\u0131 zamanda milyarlarca eski durumun silinmesi gerekti\u011fini d\u00fc\u015f\u00fcnd\u00fc\u011f\u00fcm\u00fczde, bu operasyonun ne kadar b\u00fcy\u00fck bir \u00f6l\u00e7ekte ger\u00e7ekle\u015fti\u011fi daha net anla\u015f\u0131l\u0131r. Bu \u00f6l\u00e7ekte bir veri silme i\u015flemi, veritaban\u0131 kilitlenmelerine, yava\u015flamalara ve hatta sistem \u00e7\u00f6kmelerine yol a\u00e7abilir e\u011fer do\u011fru stratejiler uygulanmazsa. \u0130\u015fte tam da bu noktada \u00f6l\u00e7eklenebilirlik (scalability) kavram\u0131 devreye girer. \u00d6l\u00e7eklenebilirlik, bir sistemin artan i\u015f y\u00fck\u00fcn\u00fc veya veri hacmini, performans\u0131n\u0131 d\u00fc\u015f\u00fcrmeden veya maliyetini orant\u0131s\u0131zca art\u0131rmadan y\u00f6netebilme yetene\u011fidir. WhatsApp gibi platformlar i\u00e7in bu, hem veri al\u0131m\u0131n\u0131 (ingestion) hem de veri silme (deletion) i\u015flemlerini milyarlarca kullan\u0131c\u0131 i\u00e7in sorunsuz bir \u015fekilde ger\u00e7ekle\u015ftirebilmek anlam\u0131na gelir.<\/p>\n
Veri ya\u015fam d\u00f6ng\u00fcs\u00fc (data lifecycle) y\u00f6netimi, bu ba\u011flamda hayati \u00f6neme sahiptir. K\u0131sa \u00f6m\u00fcrl\u00fc veriler i\u00e7in ya\u015fam d\u00f6ng\u00fcs\u00fc, verinin olu\u015fturulmas\u0131yla ba\u015flar, belirli bir s\u00fcre aktif kal\u0131r ve ard\u0131ndan silinerek sona erer. Bu d\u00f6ng\u00fcn\u00fcn her a\u015famas\u0131, \u00f6zellikle de silme a\u015famas\u0131, dikkatli bir m\u00fchendislik gerektirir. Geleneksel olarak, bir veriyi silmek, veritaban\u0131nda ilgili kayd\u0131n bulunmas\u0131n\u0131, silinmesini ve indekslerin g\u00fcncellenmesini i\u00e7erir. K\u00fc\u00e7\u00fck \u00f6l\u00e7ekte bu basit bir i\u015flemken, milyarlarca kay\u0131t i\u00e7in bu, devasa bir I\/O (giri\u015f\/\u00e7\u0131k\u0131\u015f) y\u00fck\u00fc, kilitlenme \u00e7eki\u015fmesi (lock contention) ve genel sistem yava\u015flamas\u0131 demektir. Bu nedenle, WhatsApp gibi platformlar, geleneksel veritaban\u0131 silme komutlar\u0131ndan \u00e7ok daha sofistike mekanizmalar kullanmak zorundad\u0131r. Bu mekanizmalar, veritaban\u0131 i\u015flemlerini m\u00fcmk\u00fcn oldu\u011funca da\u011f\u0131tarak, asenkron hale getirerek ve verinin kendisinin ya\u015fam s\u00fcresini y\u00f6netmesini sa\u011flayarak sistemin genel sa\u011fl\u0131\u011f\u0131n\u0131 korumay\u0131 hedefler. Dolay\u0131s\u0131yla, k\u0131sa \u00f6m\u00fcrl\u00fc verilerin etkili bir \u015fekilde y\u00f6netilmesi, sadece depolama alan\u0131n\u0131 optimize etmekle kalmaz, ayn\u0131 zamanda sistemin s\u00fcrekli olarak y\u00fcksek performansla \u00e7al\u0131\u015fmas\u0131n\u0131 da garanti eder.<\/p>\n
Geleneksel veritaban\u0131 y\u00f6netim sistemleri (RDBMS), genellikle ACID (Atomicity, Consistency, Isolation, Durability) \u00f6zelliklerini \u00f6n planda tutarak tasarlanm\u0131\u015ft\u0131r. Bu \u00f6zellikler, finansal i\u015flemler gibi verinin b\u00fct\u00fcnl\u00fc\u011f\u00fcn\u00fcn kritik oldu\u011fu senaryolarda son derece de\u011ferliyken, WhatsApp durumlar\u0131 gibi k\u0131sa \u00f6m\u00fcrl\u00fc ve y\u00fcksek hacimli veriler i\u00e7in a\u015f\u0131r\u0131ya ka\u00e7an bir y\u00fck olu\u015fturabilir. Basit bir Bu yetersizli\u011fin temel nedenlerinden biri, geleneksel silme i\u015flemlerinin genellikle veritaban\u0131 kilitlenmelerine (database locking) yol a\u00e7mas\u0131d\u0131r. Bir kay\u0131t silinirken, ilgili sat\u0131r veya hatta t\u00fcm tablo kilitlenebilir, bu da di\u011fer okuma ve yazma i\u015flemlerinin beklemesine neden olur. Milyarlarca silme i\u015flemi e\u015fzamanl\u0131 olarak ger\u00e7ekle\u015fti\u011finde, bu kilitlenmeler domino etkisi yaratarak sistem genelinde bir t\u0131kan\u0131kl\u0131\u011fa (bottleneck) yol a\u00e7ar. Ayr\u0131ca, silme i\u015flemleri genellikle yo\u011fun disk I\/O’su gerektirir. Veritaban\u0131n\u0131n diskten veriyi okumas\u0131, silmesi ve ard\u0131ndan indeksleri g\u00fcncellemesi gerekir. Bu s\u00fcrekli disk eri\u015fimi, \u00f6zellikle y\u00fcksek trafikli bir sistemde, disk alt sistemini a\u015f\u0131r\u0131 y\u00fckleyebilir ve performans\u0131 d\u00fc\u015f\u00fcrebilir. \u0130ndeks par\u00e7alanmas\u0131 (index fragmentation) da ba\u015fka bir sorundur; s\u0131k silme i\u015flemleri, indekslerin verimsiz hale gelmesine ve sorgu performans\u0131n\u0131n d\u00fc\u015fmesine neden olabilir, bu da periyodik yeniden indeksleme (re-indexing) veya s\u0131k\u0131\u015ft\u0131rma (compaction) gerektirir.<\/p>\n Bu zorluklar\u0131n \u00fcstesinden gelmek i\u00e7in WhatsApp gibi platformlar, da\u011f\u0131t\u0131k veritabanlar\u0131 (distributed databases) ve NoSQL \u00e7\u00f6z\u00fcmlerine y\u00f6nelir. Bu mimariler, veriyi birden \u00e7ok sunucuya veya d\u00fc\u011f\u00fcme (node) yayarak, tek bir noktadaki y\u00fck\u00fc azaltmay\u0131 hedefler. Veri par\u00e7alama (sharding) veya yatay \u00f6l\u00e7ekleme (horizontal scaling) olarak bilinen bu teknik, veritaban\u0131n\u0131 mant\u0131ksal veya fiziksel olarak k\u00fc\u00e7\u00fck, y\u00f6netilebilir par\u00e7alara b\u00f6ler. Her bir par\u00e7a (shard), kendi ba\u015f\u0131na bir veritaban\u0131 gibi \u00e7al\u0131\u015f\u0131r ve kendi silme i\u015flemlerini ba\u011f\u0131ms\u0131z olarak ger\u00e7ekle\u015ftirebilir. Bu sayede, milyarlarca durumun silinmesi, tek bir devasa veritaban\u0131 yerine, y\u00fczlerce veya binlerce daha k\u00fc\u00e7\u00fck veritaban\u0131 par\u00e7as\u0131nda e\u015fzamanl\u0131 olarak ger\u00e7ekle\u015fir. Bu yakla\u015f\u0131m, silme i\u015flemlerinin paralel olarak y\u00fcr\u00fct\u00fclmesini sa\u011flar ve kilitlenme \u00e7eki\u015fmesini \u00f6nemli \u00f6l\u00e7\u00fcde azalt\u0131r.<\/p>\n NoSQL veritabanlar\u0131, \u00f6zellikle Cassandra, MongoDB veya DynamoDB gibi \u00e7\u00f6z\u00fcmler, k\u0131sa \u00f6m\u00fcrl\u00fc verilerin y\u00f6netimi i\u00e7in do\u011fal avantajlar sunar. Bu veritabanlar\u0131, genellikle ACID \u00f6zelliklerinden baz\u0131lar\u0131n\u0131 (\u00f6zellikle izolasyon) gev\u015feterek y\u00fcksek \u00f6l\u00e7eklenebilirlik ve kullan\u0131labilirlik elde ederler. \u00d6rne\u011fin, Cassandra, “Time-To-Live” (TTL) mekanizmas\u0131yla entegre olarak gelir, bu da verilerin belirli bir s\u00fcre sonra otomatik olarak silinmesini sa\u011flar. Bu, geli\u015ftiricilerin manuel silme komutlar\u0131 yazma ihtiyac\u0131n\u0131 ortadan kald\u0131r\u0131r ve veritaban\u0131n\u0131n kendi kendini temizlemesine olanak tan\u0131r. Ayr\u0131ca, NoSQL veritabanlar\u0131 genellikle daha esnek veri modellerine sahiptir ve y\u00fcksek yazma\/okuma performans\u0131na odaklanm\u0131\u015flard\u0131r, bu da WhatsApp durumlar\u0131 gibi s\u00fcrekli de\u011fi\u015fen ve y\u00fcksek hacimli verilere \u00e7ok daha uygun olduklar\u0131 anlam\u0131na gelir. Bu modern veritaban\u0131 mimarileri, geleneksel veritabanlar\u0131n\u0131n kar\u015f\u0131la\u015ft\u0131\u011f\u0131 performans ve \u00f6l\u00e7eklenebilirlik sorunlar\u0131n\u0131 a\u015farak, WhatsApp gibi k\u00fcresel \u00f6l\u00e7ekteki uygulamalar\u0131n sorunsuz bir \u015fekilde \u00e7al\u0131\u015fmas\u0131n\u0131 m\u00fcmk\u00fcn k\u0131lar.<\/p>\n WhatsApp’\u0131n milyarlarca durumu veritaban\u0131n\u0131 yormadan silmesinin ard\u0131nda yatan temel stratejilerden ikisi, Zaman A\u015f\u0131m\u0131 (Time-To-Live – TTL) mekanizmalar\u0131 ve Yumu\u015fak Silme (Soft Delete) yakla\u015f\u0131mlar\u0131d\u0131r. Bu iki y\u00f6ntem, veri ya\u015fam d\u00f6ng\u00fcs\u00fcn\u00fc etkin bir \u015fekilde y\u00f6netmek ve operasyonel y\u00fck\u00fc minimize etmek i\u00e7in genellikle birlikte kullan\u0131l\u0131r.<\/p>\n Zaman A\u015f\u0131m\u0131 (TTL), belirli bir verinin ne kadar s\u00fcreyle ge\u00e7erli olaca\u011f\u0131n\u0131 tan\u0131mlayan bir mekanizmad\u0131r. WhatsApp durumlar\u0131 i\u00e7in bu s\u00fcre genellikle 24 saattir. Bu s\u00fcre sona erdi\u011finde, veritaban\u0131 veya depolama sistemi, veriyi otomatik olarak siler veya eri\u015filemez hale getirir. Bu, manuel silme komutlar\u0131 \u00e7al\u0131\u015ft\u0131rmak veya arka planda s\u00fcrekli \u00e7al\u0131\u015fan bir temizleme servisine ihtiya\u00e7 duymadan veri temizli\u011fini otomatize etmenin son derece etkili bir yoludur.<\/p>\n TTL mekanizmas\u0131, \u00f6zellikle Cassandra, MongoDB, Redis gibi NoSQL veritabanlar\u0131nda ve baz\u0131 bulut depolama hizmetlerinde (\u00f6rne\u011fin Amazon S3 ya\u015fam d\u00f6ng\u00fcs\u00fc kurallar\u0131) yerle\u015fik bir \u00f6zellik olarak bulunur. Bir veri kaydedilirken, ona bir TTL de\u011feri atan\u0131r. Veritaban\u0131, bu de\u011feri kullanarak verinin ne zaman “son kullanma tarihine” ula\u015faca\u011f\u0131n\u0131 bilir. S\u00fcre doldu\u011funda, veritaban\u0131n\u0131n arka plan s\u00fcre\u00e7leri, veriyi fiziksel olarak diskten kald\u0131r\u0131r. Bu i\u015flem genellikle d\u00fc\u015f\u00fck \u00f6ncelikli bir g\u00f6rev olarak y\u00fcr\u00fct\u00fcl\u00fcr, b\u00f6ylece ana okuma\/yazma i\u015flemlerinin performans\u0131n\u0131 etkilemez. \u00d6rne\u011fin, Cassandra’da bir sat\u0131r eklendi\u011finde veya g\u00fcncellendi\u011finde, sat\u0131ra bir TTL de\u011feri atanabilir. Bu de\u011fer, saniye cinsinden belirtilir. Cassandra, bu sat\u0131r\u0131, TTL s\u00fcresi dolduktan sonra otomatik olarak silinmek \u00fczere i\u015faretler ve arka plandaki s\u0131k\u0131\u015ft\u0131rma (compaction) s\u00fcre\u00e7leri s\u0131ras\u0131nda fiziksel olarak diskten kald\u0131r\u0131r. Bu yakla\u015f\u0131m, sistemin s\u00fcrekli olarak milyarlarca silme sorgusu \u00e7al\u0131\u015ft\u0131rmas\u0131 ihtiyac\u0131n\u0131 ortadan kald\u0131r\u0131r ve b\u00f6ylece veritaban\u0131 \u00fczerindeki y\u00fck\u00fc \u00f6nemli \u00f6l\u00e7\u00fcde azalt\u0131r. Ayr\u0131ca, geli\u015ftiricilerin veri temizli\u011fi i\u00e7in karma\u015f\u0131k mant\u0131klar yazmas\u0131na gerek kalmaz, bu da geli\u015ftirme s\u00fcrecini basitle\u015ftirir.<\/p>\n Yukar\u0131daki \u00f6rnekte, Yumu\u015fak Silme (Soft Delete), veriyi fiziksel olarak hemen silmek yerine, ona bir “silindi” i\u015fareti (flag) ekleme y\u00f6ntemidir. Bu i\u015faret genellikle bir s\u00fctun (\u00f6rne\u011fin, Yumu\u015fak silmenin birka\u00e7 \u00f6nemli avantaj\u0131 vard\u0131r. Birincisi, veri kurtarma (data recovery) yetene\u011fidir. Yanl\u0131\u015fl\u0131kla silinen bir durum, fiziksel olarak kald\u0131r\u0131lmad\u0131\u011f\u0131 i\u00e7in kolayca geri getirilebilir. \u0130kincisi, denetim (auditing) ve yasal gereklilikler i\u00e7in verinin bir s\u00fcre daha saklanabilmesidir. \u00dc\u00e7\u00fcnc\u00fcs\u00fc ve belki de en \u00f6nemlisi, fiziksel silme i\u015flemini asenkron (asynchronous) ve arka plan g\u00f6revlerine (background tasks) devrederek ana veritaban\u0131 operasyonlar\u0131n\u0131n \u00fczerindeki anl\u0131k y\u00fck\u00fc hafifletmesidir. Yani, bir durumun s\u00fcresi doldu\u011funda veya kullan\u0131c\u0131 taraf\u0131ndan silindi\u011finde, veritaban\u0131nda sadece k\u00fc\u00e7\u00fck bir g\u00fcncelleme ( Bu arka plan servisleri, genellikle belirli aral\u0131klarla WhatsApp gibi devasa \u00f6l\u00e7ekli sistemlerde, milyarlarca durumun silinmesi gibi yo\u011fun i\u015flemlerin e\u015fzamanl\u0131 ve senkron bir \u015fekilde yap\u0131lmas\u0131 m\u00fcmk\u00fcn de\u011fildir. Bu t\u00fcr bir yakla\u015f\u0131m, veritaban\u0131n\u0131 ve sunucular\u0131 an\u0131nda a\u015f\u0131r\u0131 y\u00fckleyerek hizmet kesintilerine yol a\u00e7ar. Bu nedenle, asenkron (asynchronous) ve da\u011f\u0131t\u0131k (distributed) i\u015flem modelleri, bu b\u00fcy\u00fck y\u00fckleri y\u00f6netmek i\u00e7in kritik \u00f6neme sahiptir. Bu modeller, silme i\u015flemlerini k\u00fc\u00e7\u00fck, y\u00f6netilebilir par\u00e7alara b\u00f6lerek ve bunlar\u0131 ba\u011f\u0131ms\u0131z olarak, paralel bir \u015fekilde i\u015flemeyi sa\u011flayarak sistemin genel performans\u0131n\u0131 korur.<\/p>\n Mesaj kuyruklar\u0131 (message queues), asenkron ileti\u015fimin temelini olu\u015fturan ve da\u011f\u0131t\u0131k sistemlerde yayg\u0131n olarak kullan\u0131lan bir mimari bile\u015fenidir. WhatsApp durumlar\u0131n\u0131n silinmesi gibi i\u015flemler, do\u011frudan veritaban\u0131 \u00fczerinde \u00e7al\u0131\u015ft\u0131r\u0131lmak yerine, bir mesaj kuyru\u011funa g\u00f6nderilir. Bu, “\u00fcretici-t\u00fcketici” (producer-consumer) modeline dayan\u0131r. Bir durumun s\u00fcresi doldu\u011funda veya kullan\u0131c\u0131 taraf\u0131ndan silindi\u011finde, bu silme iste\u011fi bir “mesaj” olarak formatlan\u0131r ve RabbitMQ, Apache Kafka veya Amazon SQS gibi bir mesaj kuyru\u011funa eklenir. Bu noktada, silme iste\u011fini g\u00f6nderen ana uygulama (\u00fcretici), iste\u011fin i\u015flenip i\u015flenmedi\u011fini beklemek zorunda kalmaz; kendi i\u015fine devam edebilir. Bu, ana uygulaman\u0131n performans\u0131n\u0131n kesintiye u\u011framamas\u0131n\u0131 sa\u011flar.<\/p>\n Mesaj kuyru\u011fundaki silme mesajlar\u0131, daha sonra “t\u00fcketiciler” (consumers) olarak adland\u0131r\u0131lan ayr\u0131 bir dizi servis veya worker (i\u015f\u00e7i) taraf\u0131ndan okunur. Bu t\u00fcketiciler, silme i\u015flemlerini ger\u00e7ek zamanl\u0131 olarak veya belirli aral\u0131klarla toplu (batch) olarak ger\u00e7ekle\u015ftirirler. \u00d6nemli olan nokta, birden fazla t\u00fcketicinin paralel olarak \u00e7al\u0131\u015fabilmesidir. Her bir t\u00fcketici, kuyruktan bir veya daha fazla silme mesaj\u0131 al\u0131r ve kendi veritaban\u0131 ba\u011flant\u0131lar\u0131 \u00fczerinden ilgili durumlar\u0131 siler. Bu paralellik, milyarlarca silme i\u015fleminin \u00e7ok daha k\u0131sa s\u00fcrede tamamlanmas\u0131n\u0131 sa\u011flar. \u00d6rne\u011fin, y\u00fczlerce veya binlerce worker ayn\u0131 anda silme i\u015flemlerini yapabilir, bu da tek bir veritaban\u0131 ba\u011flant\u0131s\u0131 \u00fczerinden yap\u0131lan senkron silme i\u015flemine g\u00f6re kat kat daha h\u0131zl\u0131d\u0131r.<\/p>\n Mesaj kuyruklar\u0131n\u0131n bir di\u011fer avantaj\u0131 da hata tolerans\u0131 (fault tolerance) ve yeniden deneme (retry) mekanizmalar\u0131d\u0131r. E\u011fer bir t\u00fcketici silme i\u015flemi s\u0131ras\u0131nda bir hata ile kar\u015f\u0131la\u015f\u0131rsa (\u00f6rne\u011fin, veritaban\u0131 ge\u00e7ici olarak eri\u015filemezse), mesaj kuyru\u011fu bu mesaj\u0131 tekrar i\u015flenmek \u00fczere s\u0131raya alabilir. Bu, veri kayb\u0131n\u0131 \u00f6nler ve sistemin dayan\u0131kl\u0131l\u0131\u011f\u0131n\u0131 art\u0131r\u0131r. Ayr\u0131ca, kuyruklar sayesinde sistemin yo\u011funluk d\u00f6nemlerinde gelen silme istekleri tamponlanabilir (buffered). Yo\u011funluk azald\u0131\u011f\u0131nda, t\u00fcketiciler birikmi\u015f mesajlar\u0131 i\u015flemeye devam eder. Bu esneklik, WhatsApp gibi s\u00fcrekli y\u00fcksek y\u00fck alt\u0131nda \u00e7al\u0131\u015fan platformlar i\u00e7in vazge\u00e7ilmezdir. Mesaj kuyruklar\u0131, silme i\u015flemlerini ana i\u015f mant\u0131\u011f\u0131ndan ay\u0131rarak, sistemin genel mimarisini daha mod\u00fcler, \u00f6l\u00e7eklenebilir ve dayan\u0131kl\u0131 hale getirir.<\/p>\n Veri par\u00e7alama (sharding), b\u00fcy\u00fck veritabanlar\u0131n\u0131 daha k\u00fc\u00e7\u00fck, y\u00f6netilebilir par\u00e7alara (shard) b\u00f6lme i\u015flemidir. Her bir shard, veritaban\u0131n\u0131n bir alt k\u00fcmesini i\u00e7erir ve kendi ba\u015f\u0131na ba\u011f\u0131ms\u0131z bir veritaban\u0131 gibi \u00e7al\u0131\u015f\u0131r. WhatsApp gibi k\u00fcresel \u00f6l\u00e7ekte hizmet veren bir uygulamada, kullan\u0131c\u0131 verileri genellikle co\u011frafi olarak da\u011f\u0131t\u0131lm\u0131\u015f veri merkezlerinde (data centers) depolan\u0131r. Bu, hem d\u00fc\u015f\u00fck gecikme s\u00fcresi (low latency) sa\u011flamak hem de sistemin dayan\u0131kl\u0131l\u0131\u011f\u0131n\u0131 art\u0131rmak i\u00e7in yap\u0131l\u0131r. Veri par\u00e7alama ve co\u011frafi da\u011f\u0131t\u0131m, silme i\u015flemlerinin verimli bir \u015fekilde y\u00f6netilmesinde kritik bir rol oynar.<\/p>\n Bir WhatsApp durumu olu\u015fturuldu\u011funda, genellikle kullan\u0131c\u0131n\u0131n co\u011frafi konumuna veya kullan\u0131c\u0131 ID’sine (kimli\u011fine) g\u00f6re belirli bir shard’a atan\u0131r. Bu, kullan\u0131c\u0131n\u0131n t\u00fcm durumlar\u0131n\u0131n ve ilgili verilerinin ayn\u0131 shard \u00fczerinde depolanmas\u0131n\u0131 sa\u011flar. Durumun s\u00fcresi doldu\u011funda veya silinmek \u00fczere i\u015faretlendi\u011finde, bu silme i\u015flemi yaln\u0131zca ilgili shard \u00fczerinde ger\u00e7ekle\u015ftirilir. Yani, milyarlarca durumun silinmesi, tek bir merkezi veritaban\u0131nda de\u011fil, y\u00fczlerce veya binlerce ba\u011f\u0131ms\u0131z shard \u00fczerinde paralel olarak ger\u00e7ekle\u015fir. Her shard, kendi \u00fczerinde biriken silme y\u00fck\u00fcn\u00fc kendi ba\u015f\u0131na y\u00f6netir. Bu, tek bir veritaban\u0131 \u00fczerinde olu\u015fabilecek kilitlenme \u00e7eki\u015fmesini ve I\/O y\u00fck\u00fcn\u00fc dramatik bir \u015fekilde azalt\u0131r.<\/p>\n Co\u011frafi da\u011f\u0131t\u0131m, veri par\u00e7alamay\u0131 bir ad\u0131m \u00f6teye ta\u015f\u0131r. Veri par\u00e7alar\u0131, d\u00fcnyan\u0131n farkl\u0131 b\u00f6lgelerindeki veri merkezlerine da\u011f\u0131t\u0131l\u0131r. \u00d6rne\u011fin, Avrupa’daki kullan\u0131c\u0131lar\u0131n durumlar\u0131 Avrupa’daki bir veri merkezindeki shard’larda, Asya’daki kullan\u0131c\u0131lar\u0131n durumlar\u0131 ise Asya’daki bir veri merkezindeki shard’larda depolan\u0131r. Bu mimari, sadece kullan\u0131c\u0131lar\u0131n durumlar\u0131na daha h\u0131zl\u0131 eri\u015fmesini sa\u011flamakla kalmaz, ayn\u0131 zamanda silme i\u015flemlerinin de co\u011frafi olarak da\u011f\u0131t\u0131lmas\u0131n\u0131 sa\u011flar. Bir veri merkezindeki silme i\u015flemleri, di\u011fer veri merkezlerindeki i\u015flemleri etkilemez. Bu, bir b\u00f6lgedeki potansiyel bir sorun veya a\u015f\u0131r\u0131 y\u00fck\u00fcn, k\u00fcresel sistemi \u00e7\u00f6kertmesini engeller. Her bir veri merkezindeki shard’lar, kendi TTL mekanizmalar\u0131n\u0131 ve arka plan silme servislerini \u00e7al\u0131\u015ft\u0131r\u0131r. Bu sayede, WhatsApp, milyarlarca durum verisini, veritaban\u0131n\u0131n performans\u0131n\u0131 d\u00fc\u015f\u00fcrmeden, hatta fark edilmeden temizleyebilir. Veri par\u00e7alama ve co\u011frafi da\u011f\u0131t\u0131m\u0131n birle\u015fimi, WhatsApp’a sadece \u00f6l\u00e7eklenebilirlik de\u011fil, ayn\u0131 zamanda y\u00fcksek kullan\u0131labilirlik ve felaket kurtarma (disaster recovery) yetenekleri de kazand\u0131r\u0131r.<\/p>\n WhatsApp gibi kritik sistemlerde, veri silme i\u015flemlerinin sorunsuz bir \u015fekilde y\u00fcr\u00fct\u00fclmesi, sadece do\u011fru mimariyi kurmakla kalmaz, ayn\u0131 zamanda operasyonel m\u00fckemmelli\u011fi de gerektirir. Bu, s\u00fcrekli izleme, d\u00fczenli bak\u0131m ve sa\u011flam felaket kurtarma stratejileri anlam\u0131na gelir. Bu unsurlar, sistemin s\u00fcrekli olarak y\u00fcksek performansla \u00e7al\u0131\u015fmas\u0131n\u0131 ve olas\u0131 sorunlar\u0131n h\u0131zla tespit edilip \u00e7\u00f6z\u00fclmesini sa\u011flar.<\/p>\n \u0130zleme (monitoring), b\u00fcy\u00fck veri silme operasyonlar\u0131n\u0131n kalbinde yer al\u0131r. Sistem m\u00fchendisleri ve DevOps ekipleri, veritaban\u0131 sunucular\u0131n\u0131n sa\u011fl\u0131k durumunu, disk I\/O oranlar\u0131n\u0131, CPU kullan\u0131m\u0131n\u0131, bellek t\u00fcketimini ve a\u011f trafi\u011fini s\u00fcrekli olarak takip ederler. \u00d6zellikle silme i\u015flemleriyle ilgili metrikler hayati \u00f6neme sahiptir: Ka\u00e7 durumun silindi\u011fi, silme kuyruklar\u0131ndaki mesaj say\u0131s\u0131, t\u00fcketicilerin silme h\u0131zlar\u0131 ve silme i\u015flemlerinde ya\u015fanan hata oranlar\u0131 gibi g\u00f6stergeler s\u00fcrekli izlenir. Anormal art\u0131\u015flar veya d\u00fc\u015f\u00fc\u015fler, potansiyel bir sorunun habercisi olabilir. \u00d6rne\u011fin, silme kuyruklar\u0131nda birikme ya\u015fan\u0131yorsa, bu t\u00fcketicilerin yetersiz kald\u0131\u011f\u0131na veya bir veritaban\u0131 sorununa i\u015faret edebilir. Bu metrikler, Prometheus, Grafana, Splunk gibi ara\u00e7lar kullan\u0131larak ger\u00e7ek zamanl\u0131 panolarda (dashboards) g\u00f6rselle\u015ftirilir ve belirli e\u015fik de\u011ferler a\u015f\u0131ld\u0131\u011f\u0131nda otomatik uyar\u0131lar (alerts) tetiklenir. Bu proaktif yakla\u015f\u0131m, k\u00fc\u00e7\u00fck sorunlar\u0131n b\u00fcy\u00fcmeden \u00f6nce tespit edilip giderilmesini sa\u011flar.<\/p>\n Veritaban\u0131 bak\u0131m\u0131 (database maintenance), k\u0131sa \u00f6m\u00fcrl\u00fc verilerin yo\u011fun olarak kullan\u0131ld\u0131\u011f\u0131 sistemlerde kritik \u00f6neme sahiptir. S\u0131k silme i\u015flemleri, veritaban\u0131 dosyalar\u0131nda “bo\u015fluklar” veya “par\u00e7alanma” (fragmentation) yaratabilir. Bu bo\u015fluklar, disk alan\u0131n\u0131n verimsiz kullan\u0131lmas\u0131na ve sorgu performans\u0131n\u0131n d\u00fc\u015fmesine neden olabilir. Bu nedenle, veritaban\u0131 sistemleri, belirli aral\u0131klarla s\u0131k\u0131\u015ft\u0131rma (compaction) veya otomatik \u00e7\u00f6p toplama (garbage collection) i\u015flemleri y\u00fcr\u00fct\u00fcr. Bu i\u015flemler, silinmi\u015f verilerin fiziksel olarak diskten kald\u0131r\u0131lmas\u0131n\u0131, bo\u015f alanlar\u0131n geri kazan\u0131lmas\u0131n\u0131 ve veritaban\u0131 dosyalar\u0131n\u0131n daha d\u00fczenli hale getirilmesini sa\u011flar. \u00d6rne\u011fin, Apache Cassandra’da s\u0131k\u0131\u015ft\u0131rma stratejileri, silinen verilerin temizlenmesi ve disk alan\u0131n\u0131n optimize edilmesi i\u00e7in hayati bir rol oynar. Bu bak\u0131m i\u015flemleri genellikle sistemin daha az yo\u011fun oldu\u011fu saatlerde veya arka planda, ana i\u015f y\u00fck\u00fcn\u00fc etkilemeyecek \u015fekilde planlan\u0131r ve y\u00fcr\u00fct\u00fcl\u00fcr.<\/p>\n Felaket kurtarma (disaster recovery) stratejileri, k\u0131sa \u00f6m\u00fcrl\u00fc verilerin do\u011fas\u0131 gere\u011fi farkl\u0131 bir boyut kazan\u0131r. Geleneksel olarak, felaket kurtarma, veritaban\u0131n\u0131n belirli bir noktaya geri y\u00fcklenmesini (point-in-time recovery) i\u00e7erir. Ancak, WhatsApp durumlar\u0131 gibi 24 saatlik \u00f6mre sahip veriler i\u00e7in, g\u00fcnlerce veya haftalarca geriye d\u00f6n\u00fck yedekler tutmak mant\u0131ks\u0131z ve maliyetli olacakt\u0131r. Bunun yerine, felaket kurtarma stratejileri, sistemin genel kullan\u0131labilirli\u011fine ve veri ak\u0131\u015f\u0131n\u0131n devaml\u0131l\u0131\u011f\u0131na odaklan\u0131r. Bu, genellikle \u00e7oklu b\u00f6lge (multi-region) veya \u00e7oklu veri merkezi (multi-datacenter) mimarileriyle sa\u011flan\u0131r. Bir veri merkezinin tamamen \u00e7\u00f6kmesi durumunda bile, di\u011fer veri merkezlerindeki kopyalar hizmet vermeye devam edebilir. K\u0131sa \u00f6m\u00fcrl\u00fc veriler i\u00e7in, veri kayb\u0131 tolerans\u0131 (data loss tolerance) genellikle daha y\u00fcksektir; yani, son birka\u00e7 saatlik durum verisinin kayb\u0131, uzun \u00f6m\u00fcrl\u00fc ve kritik finansal verilerin kayb\u0131 kadar y\u0131k\u0131c\u0131 kabul edilmeyebilir. Bu nedenle, WhatsApp’\u0131n felaket kurtarma stratejileri, verinin anl\u0131k olarak \u00e7o\u011falt\u0131lmas\u0131na (replication) ve sistemin h\u0131zla ba\u015fka bir b\u00f6lgeye ge\u00e7i\u015f yapabilmesine (failover) odaklan\u0131r, b\u00f6ylece kullan\u0131c\u0131lar hizmet kesintisi ya\u015famadan durumlar\u0131n\u0131 g\u00f6rmeye ve payla\u015fmaya devam edebilirler. \u0130zleme, bak\u0131m ve felaket kurtarma, WhatsApp’\u0131n her g\u00fcn milyarlarca durumu g\u00fcvenli ve verimli bir \u015fekilde silmesini sa\u011flayan operasyonel m\u00fckemmelli\u011fin temel ta\u015flar\u0131d\u0131r.<\/p>\n WhatsApp’\u0131n milyarlarca durumu her g\u00fcn veritaban\u0131n\u0131 \u00e7\u00f6kertmeden nas\u0131l sildi\u011fini daha iyi anlamak i\u00e7in, yukar\u0131da tart\u0131\u015ft\u0131\u011f\u0131m\u0131z t\u00fcm teknikleri bir araya getiren hipotetik ama ger\u00e7ek\u00e7i bir senaryo olu\u015ftural\u0131m. Bu senaryo, bir kullan\u0131c\u0131n\u0131n durum payla\u015f\u0131m\u0131ndan, durumun otomatik olarak sistemden kald\u0131r\u0131lmas\u0131na kadar ge\u00e7en s\u00fcreci ad\u0131m ad\u0131m a\u00e7\u0131klayacakt\u0131r.<\/p>\n Bir kullan\u0131c\u0131 WhatsApp uygulamas\u0131nda yeni bir durum (\u00f6rne\u011fin, bir foto\u011fraf veya k\u0131sa bir video) olu\u015fturdu\u011funda ve “Payla\u015f” d\u00fc\u011fmesine bast\u0131\u011f\u0131nda, uygulama bu durumu WhatsApp sunucular\u0131na g\u00f6nderir. Sunucular, bu durumu i\u015fler ve kullan\u0131c\u0131n\u0131n co\u011frafi konumuna veya kullan\u0131c\u0131 kimli\u011fine (ID) g\u00f6re belirlenmi\u015f bir veri par\u00e7as\u0131na (shard) y\u00f6nlendirir. Bu shard, genellikle da\u011f\u0131t\u0131k bir NoSQL veritaban\u0131 (\u00f6rne\u011fin, Apache Cassandra) \u00fczerinde \u00e7al\u0131\u015f\u0131r.<\/p>\n Durum veritaban\u0131na kaydedilirken, ona 24 saatlik bir Zaman A\u015f\u0131m\u0131 (TTL) de\u011feri atan\u0131r. Bu, durumun 24 saat sonra otomatik olarak silinmek \u00fczere i\u015faretlenece\u011fi anlam\u0131na gelir. Bu a\u015famada, veritaban\u0131 \u00fczerinde sadece bir yazma i\u015flemi ger\u00e7ekle\u015fir ve TTL \u00f6zelli\u011fi sayesinde manuel bir silme komutu d\u00fc\u015f\u00fcn\u00fclmez. \u00d6rne\u011fin, durum kayd\u0131na Kullan\u0131c\u0131lar ve onlar\u0131n ba\u011flant\u0131lar\u0131, durumlar\u0131 kendi uygulamalar\u0131 \u00fczerinden talep etti\u011finde, sistem ilgili shard’a sorgu g\u00f6nderir. Bu sorgular, sadece Bir durumun 24 saatlik \u00f6mr\u00fc sona erdi\u011finde, veritaban\u0131n\u0131n arka plan s\u00fcre\u00e7leri devreye girer. Cassandra gibi bir veritaban\u0131nda, bu s\u00fcre\u00e7ler (\u00f6rne\u011fin, s\u0131k\u0131\u015ft\u0131rma veya \u00e7\u00f6p toplama mekanizmalar\u0131), TTL s\u00fcresi dolmu\u015f verileri otomatik olarak tespit eder ve bunlar\u0131 fiziksel olarak diskten kald\u0131r\u0131r. Bu i\u015flem, d\u00fc\u015f\u00fck \u00f6ncelikli bir arka plan g\u00f6revi olarak y\u00fcr\u00fct\u00fcl\u00fcr ve veritaban\u0131n\u0131n ana okuma\/yazma i\u015flemlerini etkilemez. Bu, milyarlarca durumu tek tek silmek yerine, veritaban\u0131n\u0131n kendi kendini temizlemesini sa\u011flayan, son derece verimli bir y\u00f6ntemdir.<\/p>\n<\/li>\n E\u011fer bir kullan\u0131c\u0131, durumunun 24 saat dolmadan \u00f6nce kendisi silmeye karar verirse, uygulama sunucuya bir silme iste\u011fi g\u00f6nderir. Bu durumda, durum fiziksel olarak hemen silinmez. Bunun yerine, ilgili durum kayd\u0131ndaki Bu yumu\u015fak silinmi\u015f durumlar, kullan\u0131c\u0131 aray\u00fcz\u00fcnde art\u0131k g\u00f6sterilmez. Ancak fiziksel olarak hala veritaban\u0131nda dururlar. Daha sonra, ayr\u0131 bir arka plan servisi veya worker grubu, belirli aral\u0131klarla (\u00f6rne\u011fin, geceleri veya d\u00fc\u015f\u00fck yo\u011funluklu zamanlarda) Hem otomatik TTL tabanl\u0131 silme hem de manuel yumu\u015fak silme sonras\u0131 fiziksel temizleme i\u015flemleri, da\u011f\u0131t\u0131k sistem mimarisinin nimetlerinden faydalan\u0131r. Silme istekleri veya silinmesi gereken durumlar\u0131n listesi, mesaj kuyruklar\u0131na (Kafka gibi) g\u00f6nderilir. Bu kuyruklar, y\u00fczlerce veya binlerce t\u00fcketici worker taraf\u0131ndan paralel olarak i\u015flenir. Her worker, kendi shard’\u0131ndaki veriyi silmekten sorumludur. Bu sayede, milyarlarca silme i\u015flemi, tek bir noktada t\u0131kan\u0131kl\u0131k yaratmadan, e\u015fzamanl\u0131 ve verimli bir \u015fekilde ger\u00e7ekle\u015ftirilir.<\/p>\n<\/li>\n T\u00fcm bu s\u00fcre\u00e7 boyunca, sistemin durumu s\u00fcrekli olarak izlenir. Veritaban\u0131 performans\u0131, disk kullan\u0131m\u0131, silme kuyruklar\u0131ndaki birikme ve worker’lar\u0131n sa\u011fl\u0131k durumu gibi metrikler takip edilir. Periyodik veritaban\u0131 s\u0131k\u0131\u015ft\u0131rma ve bak\u0131m i\u015flemleri, sistemin optimum performansta kalmas\u0131n\u0131 sa\u011flar.<\/p>\n<\/li>\n<\/ol>\n \u00d6zetle, WhatsApp, milyarlarca durumu silmek i\u00e7in TTL, yumu\u015fak silme, mesaj kuyruklar\u0131 ve veri par\u00e7alama gibi geli\u015fmi\u015f tekniklerin bir kombinasyonunu kullan\u0131r. Bu \u00e7ok katmanl\u0131 strateji, hem anl\u0131k performans\u0131 garanti eder hem de veritaban\u0131n\u0131n a\u015f\u0131r\u0131 y\u00fcklenmesini engelleyerek, kullan\u0131c\u0131 deneyimini kesintisiz hale getirir.<\/p>\n WhatsApp’\u0131n her g\u00fcn milyarlarca durumu veritaban\u0131n\u0131 \u00e7\u00f6kertmeden silme yetene\u011fi, modern b\u00fcy\u00fck veri mimarisinin ve da\u011f\u0131t\u0131k sistemlerin bir zaferidir. Bu s\u00fcre\u00e7, sadece basit bir WhatsApp durumlar\u0131 gibi k\u0131sa \u00f6m\u00fcrl\u00fc verilerin her g\u00fcn milyarlarca adet \u00fcretilip ayn\u0131 h\u0131zda silinmesi gerekir. Geleneksel veritaban\u0131 silme y\u00f6ntemleri (manuel DELETE komutlar\u0131), bu \u00f6l\u00e7ekte veritaban\u0131 kilitlenmelerine, yo\u011fun disk I\/O’suna ve performans d\u00fc\u015f\u00fc\u015flerine yol a\u00e7arak sistemi \u00e7\u00f6kertme riski ta\u015f\u0131r. Bu nedenle \u00f6zel mimariler ve stratejiler gereklidir.<\/p>\n<\/li>\n TTL, bir verinin belirli bir s\u00fcre sonra otomatik olarak silinmesini sa\u011flayan bir mekanizmad\u0131r. WhatsApp, durumlar\u0131 veritaban\u0131na kaydederken onlara 24 saatlik bir TTL de\u011feri atar. S\u00fcre doldu\u011funda, veritaban\u0131 (\u00f6rne\u011fin Cassandra), bu durumu otomatik olarak arka planda fiziksel olarak diskten kald\u0131r\u0131r. Bu, manuel silme komutlar\u0131na gerek kalmadan otomatik temizlik sa\u011flar.<\/p>\n<\/li>\n Yumu\u015fak silme, bir veriyi hemen fiziksel olarak veritaban\u0131ndan kald\u0131rmak yerine, ona bir “silindi” i\u015fareti (\u00f6rne\u011fin, Mesaj kuyruklar\u0131, silme i\u015flemlerini asenkron hale getirerek ana uygulaman\u0131n y\u00fck\u00fcn\u00fc hafifletir. Bir durumun silinmesi gerekti\u011finde, bu bir mesaj olarak kuyru\u011fa eklenir. Ayr\u0131 \u00e7al\u0131\u015fan “worker” servisleri, bu mesajlar\u0131 kuyruktan al\u0131r ve paralel olarak silme i\u015flemlerini ger\u00e7ekle\u015ftirir. Bu, veritaban\u0131 \u00fczerindeki ani y\u00fck\u00fc yayar ve i\u015flemleri \u00f6l\u00e7eklenebilir k\u0131lar.<\/p>\n<\/li>\n Veri par\u00e7alama, veritaban\u0131n\u0131 daha k\u00fc\u00e7\u00fck, ba\u011f\u0131ms\u0131z par\u00e7alara (shard) b\u00f6ler. Her bir shard, kendi verilerini ve i\u015flem y\u00fck\u00fcn\u00fc y\u00f6netir. WhatsApp’ta durum verileri farkl\u0131 shard’lara da\u011f\u0131t\u0131ld\u0131\u011f\u0131 i\u00e7in, silme i\u015flemleri de bu shard’lar aras\u0131nda paralel olarak y\u00fcr\u00fct\u00fcl\u00fcr. Bu, tek bir veritaban\u0131 \u00fczerinde olu\u015fabilecek t\u0131kan\u0131kl\u0131\u011f\u0131 \u00f6nler ve sistemin milyarlarca silme i\u015flemini ayn\u0131 anda, verimli bir \u015fekilde ger\u00e7ekle\u015ftirmesini sa\u011flar.<\/p>\n<\/li>\n<\/ul>\n #Teknoloji #Veritaban\u0131 #B\u00fcy\u00fckVeri #WhatsApp #Yaz\u0131l\u0131mMimarisi<\/p>\nDELETE FROM table WHERE status_id = '...'<\/code> komutu, k\u00fc\u00e7\u00fck \u00f6l\u00e7ekli uygulamalar i\u00e7in yeterli olabilir. Ancak, WhatsApp’\u0131n g\u00fcnde milyarlarca durum sildi\u011fini d\u00fc\u015f\u00fcnd\u00fc\u011f\u00fcm\u00fczde, bu yakla\u015f\u0131m h\u0131zla yetersiz kal\u0131r ve veritaban\u0131n\u0131 dizlerinin \u00fczerine \u00e7\u00f6kertir.<\/p>\nWhatsApp’\u0131n S\u0131rr\u0131: Zaman A\u015f\u0131m\u0131 (TTL) ve Yumu\u015fak Silme (Soft Delete) Stratejileri<\/h2>\n
Zaman A\u015f\u0131m\u0131 (Time-To-Live – TTL) Mekanizmalar\u0131 Nas\u0131l \u00c7al\u0131\u015f\u0131r?<\/h3>\n
-- Cassandra'da TTL ile bir kay\u0131t ekleme \u00f6rne\u011fi\nINSERT INTO whatsapp_statuses (user_id, status_id, status_text, created_at)\nVALUES ('user123', 'status456', 'Bug\u00fcn harika bir g\u00fcn!', '2023-10-27 10:00:00')\nUSING TTL 86400; -- 24 saat = 86400 saniye<\/code><\/pre>\n<\/p><\/div>\nUSING TTL 86400<\/code> ifadesi, bu durumun 24 saat sonra otomatik olarak silinece\u011fini belirtir. Bu sayede, WhatsApp gibi uygulamalar, kullan\u0131c\u0131lar\u0131n durumlar\u0131n\u0131 manuel olarak silmekle u\u011fra\u015fmak zorunda kalmazlar ve veritaban\u0131 da bu temizlik i\u015flemini kendi ba\u015f\u0131na, verimli bir \u015fekilde y\u00f6netir.<\/p>\nYumu\u015fak Silme (Soft Delete): Veriyi Hemen Yok Etmek Yerine Ne Yap\u0131l\u0131r?<\/h3>\n
is_deleted<\/code> boolean veya deleted_at<\/code> timestamp) arac\u0131l\u0131\u011f\u0131yla yap\u0131l\u0131r. Kullan\u0131c\u0131 bir durumu sildi\u011finde veya s\u00fcresi doldu\u011funda, sistem veriyi hemen veritaban\u0131ndan kald\u0131rmaz, bunun yerine bu i\u015fareti “true” yapar veya silme zaman\u0131n\u0131 kaydeder. Uygulama katman\u0131, sorgular\u0131nda yaln\u0131zca is_deleted = false<\/code> olan kay\u0131tlar\u0131 g\u00f6stererek, silinmi\u015f verilerin kullan\u0131c\u0131 aray\u00fcz\u00fcnde g\u00f6r\u00fcnmesini engeller.<\/p>\nis_deleted<\/code> s\u00fctununu de\u011fi\u015ftirmek) yap\u0131l\u0131r. Bu, milyarlarca kay\u0131t i\u00e7in bile h\u0131zl\u0131 ve d\u00fc\u015f\u00fck maliyetli bir i\u015flemdir. As\u0131l fiziksel silme, daha sonra, sistemin daha az yo\u011fun oldu\u011fu zamanlarda veya ayr\u0131 bir arka plan servisi taraf\u0131ndan yava\u015f ve kontroll\u00fc bir \u015fekilde ger\u00e7ekle\u015ftirilir.<\/p>\nis_deleted = true<\/code> ve belirli bir s\u00fcre ge\u00e7mi\u015f (\u00f6rne\u011fin, 24 saatten fazla olmu\u015f) kay\u0131tlar\u0131 tarar ve bunlar\u0131 fiziksel olarak siler. Bu i\u015flem, genellikle toplu (batch) olarak yap\u0131l\u0131r ve veritaban\u0131 \u00fczerindeki ani y\u00fck\u00fc yayar. Yumu\u015fak silme ve TTL mekanizmalar\u0131 bir arada kullan\u0131ld\u0131\u011f\u0131nda, verinin ya\u015fam d\u00f6ng\u00fcs\u00fc daha da verimli y\u00f6netilir. \u00d6rne\u011fin, bir durum yay\u0131nland\u0131\u011f\u0131nda TTL atan\u0131r. Kullan\u0131c\u0131 durumu manuel olarak silerse, is_deleted<\/code> i\u015fareti true yap\u0131l\u0131r. TTL s\u00fcresi doldu\u011funda ise, veritaban\u0131 otomatik olarak bu kayd\u0131 silinmek \u00fczere i\u015faretler. Her iki durumda da, fiziksel silme i\u015flemi, ana sistemin performans\u0131n\u0131 etkilemeden, daha sonra ve kontroll\u00fc bir \u015fekilde ger\u00e7ekle\u015ftirilir. Bu hibrit yakla\u015f\u0131m, hem anl\u0131k performans gereksinimlerini kar\u015f\u0131lar hem de veri b\u00fct\u00fcnl\u00fc\u011f\u00fc ve kurtar\u0131labilirlik gibi ek avantajlar sunar.<\/p>\nAsenkron ve Da\u011f\u0131t\u0131k Silme \u0130\u015flemleri: B\u00fcy\u00fck Y\u00fckleri Y\u00f6netmek<\/h2>\n
Mesaj Kuyruklar\u0131 (Message Queues) ile Silme \u0130\u015flemlerini Paralelle\u015ftirmek<\/h3>\n
Veri Par\u00e7alama (Sharding) ve Co\u011frafi Da\u011f\u0131t\u0131m\u0131n \u00d6nemi<\/h3>\n
Operasyonel M\u00fckemmellik: \u0130zleme, Bak\u0131m ve Felaket Kurtarma<\/h2>\n
Vaka Analizi: WhatsApp Durum Silme S\u00fcreci Bir Bak\u0131\u015fta<\/h2>\n
\n
Durum Olu\u015fturma ve Yay\u0131nlama:<\/h3>\n
created_at<\/code> zaman damgas\u0131 ve expires_at<\/code> zaman damgas\u0131 eklenir, ancak TTL mekanizmas\u0131 genellikle bu expires_at<\/code> de\u011ferini otomatik olarak y\u00f6netir.<\/p>\n<\/li>\nDurumun G\u00f6r\u00fcnt\u00fclenmesi ve Eri\u015fimi:<\/h3>\n
TTL<\/code> s\u00fcresi dolmam\u0131\u015f veya is_deleted<\/code> i\u015fareti “false” olan durumlar\u0131 getirir. Uygulama katman\u0131, verilerin g\u00fcncel ve ge\u00e7erli oldu\u011fundan emin olur.<\/p>\n<\/li>\nOtomatik Silme S\u00fcrecinin Ba\u015flamas\u0131 (TTL ile):<\/h3>\n
Kullan\u0131c\u0131 Taraf\u0131ndan Manuel Silme (Yumu\u015fak Silme ile):<\/h3>\n
is_deleted<\/code> s\u00fctunu “true” olarak g\u00fcncellenir veya deleted_at<\/code> s\u00fctununa mevcut zaman damgas\u0131 yaz\u0131l\u0131r. Bu bir “yumu\u015fak silme” i\u015flemidir ve veritaban\u0131 \u00fczerinde yaln\u0131zca k\u00fc\u00e7\u00fck bir yazma i\u015flemi gerektirir, bu da \u00e7ok h\u0131zl\u0131d\u0131r.<\/p>\nis_deleted = true<\/code> olan ve belirli bir ya\u015fa (\u00f6rne\u011fin, 24 saatten fazla olmu\u015f) ula\u015fm\u0131\u015f durumlar\u0131 tarar ve bunlar\u0131 fiziksel olarak veritaban\u0131ndan siler. Bu fiziksel silme i\u015flemi de mesaj kuyruklar\u0131 arac\u0131l\u0131\u011f\u0131yla asenkron ve paralel olarak y\u00fcr\u00fct\u00fclebilir, b\u00f6ylece veritaban\u0131 \u00fczerindeki ani y\u00fck yay\u0131l\u0131r.<\/p>\n<\/li>\nAsenkron ve Da\u011f\u0131t\u0131k \u0130\u015fleme:<\/h3>\n
\u0130zleme ve Bak\u0131m:<\/h3>\n
Sonu\u00e7 ve S\u0131k\u00e7a Sorulan Sorular<\/h2>\n
DELETE<\/code> komutu \u00e7al\u0131\u015ft\u0131rmaktan \u00e7ok daha fazlas\u0131n\u0131 i\u00e7erir; aksine, \u00f6zenle tasarlanm\u0131\u015f, \u00e7ok katmanl\u0131 bir stratejiler b\u00fct\u00fcn\u00fcd\u00fcr. Zaman A\u015f\u0131m\u0131 (TTL) mekanizmalar\u0131, verilerin otomatik olarak kendi kendini temizlemesini sa\u011flayarak operasyonel y\u00fck\u00fc minimize ederken, Yumu\u015fak Silme (Soft Delete) yakla\u015f\u0131m\u0131, veri b\u00fct\u00fcnl\u00fc\u011f\u00fcn\u00fc korur ve fiziksel silme i\u015flemlerini asenkron arka plan g\u00f6revlerine devreder. Mesaj kuyruklar\u0131 ve veri par\u00e7alama (sharding) gibi da\u011f\u0131t\u0131k sistem prensipleri, bu devasa silme y\u00fck\u00fcn\u00fcn paralel ve verimli bir \u015fekilde y\u00f6netilmesini m\u00fcmk\u00fcn k\u0131lar. Sonu\u00e7 olarak, WhatsApp gibi platformlar, bu teknikleri bir araya getirerek, hem performans\u0131 hem de \u00f6l\u00e7eklenebilirli\u011fi koruyarak milyarlarca kullan\u0131c\u0131s\u0131na kesintisiz bir deneyim sunmay\u0131 ba\u015far\u0131r. Bu karma\u015f\u0131k ancak etkili mimari, g\u00fcn\u00fcm\u00fcz\u00fcn veri yo\u011fun d\u00fcnyas\u0131nda b\u00fcy\u00fck \u00f6l\u00e7ekli uygulamalar i\u00e7in bir standart olu\u015fturmaktad\u0131r.<\/p>\nS\u0131k\u00e7a Sorulan Sorular<\/h3>\n
\n
WhatsApp durumlar\u0131n\u0131n silinmesi neden bu kadar zor bir m\u00fchendislik problemidir?<\/h4>\n
Time-To-Live (TTL) nedir ve WhatsApp bunu nas\u0131l kullan\u0131r?<\/h4>\n
Yumu\u015fak Silme (Soft Delete) ile fiziksel silme aras\u0131ndaki fark nedir?<\/h4>\n
is_deleted<\/code> alan\u0131) ekleme y\u00f6ntemidir. Uygulama, bu i\u015faretli verileri g\u00f6stermez. Fiziksel silme ise, verinin diskten tamamen kald\u0131r\u0131lmas\u0131d\u0131r. Yumu\u015fak silme, veri kurtarma ve denetim avantajlar\u0131 sunarken, fiziksel silme i\u015flemini daha sonra, sistemin daha az yo\u011fun oldu\u011fu zamanlara veya ayr\u0131 arka plan servislerine devreder.<\/p>\n<\/li>\nMesaj kuyruklar\u0131 (\u00f6rne\u011fin Kafka) silme i\u015flemlerinde nas\u0131l bir rol oynar?<\/h4>\n
Veri par\u00e7alama (sharding) WhatsApp’\u0131n \u00f6l\u00e7eklenebilirli\u011fine nas\u0131l katk\u0131da bulunur?<\/h4>\n