Cloudflare R2 ile Otomatik Veri Yükleme ve Depolama Yönetimi

Dosya yüklemek ilk bakışta basit görünür: istemciden dosyayı alır, depolama alanına yazarsınız ve iş biter. Gerçek bir production sistemi kurulduğunda ise güvenlik, büyük dosya yönetimi, otomatik temizleme, erişim politikaları, maliyet, veri bütünlüğü ve hata toleransı aynı anda devreye girer. Cloudflare R2 ile Otomatik Veri Yükleme ve Depolama Yönetimi tam olarak bu noktada yalnızca bir depolama tercihi değil, bütün bir veri akışı tasarımına dönüşür. Bu rehberde Cloudflare R2 otomatik dosya yükleme nasıl yapılır, Cloudflare R2 S3 API ile veri yükleme ve depolama yönetimi nasıl planlanır ve production ortamında hangi güvenlik kontrollerinin gerekli olduğu adım adım ele alınacak. Ayrıca presigned URL, multipart upload, lifecycle, event notifications, backup otomasyonu ve storage maliyet yönetimini aynı mimari içinde nasıl birleştirebileceğinizi göreceksiniz.

Cloudflare R2 Nedir?

Cloudflare R2, dosya ve binary verileri object storage yaklaşımıyla saklamaya yönelik bir depolama hizmetidir. Uygulamanız görselleri, arşivleri, yedekleri, logları veya kullanıcı tarafından yüklenen içerikleri nesne olarak saklayabilir. R2'nin S3 uyumlu API yaklaşımı, mevcut birçok araç ve SDK ile entegrasyonu kolaylaştırır. Bununla birlikte object storage, klasik sunucu diskinden farklı düşünülmelidir. Sağlam bir sistem kurmak için bucket, object key, metadata, lifecycle ve erişim modeli daha en başta doğru planlanmalıdır.

Object Storage Nedir?

Object storage, veriyi dosya sistemi klasörleri yerine benzersiz key değerleriyle adreslenen nesneler olarak tutar. Her object kendi içeriğine, key değerine ve belirli metadata bilgilerine sahip olabilir. Bu model yatay ölçeklenebilirlik ve büyük veri hacimleri için oldukça kullanışlıdır. Uygulama tarafı fiziksel disk konumu veya klasör yapısı yönetmek zorunda kalmaz. Buna karşılık object storage bir ilişkisel veritabanı olmadığı için gelişmiş sorgulama ve metadata araması ayrı sistemlerle çözülmelidir.

Cloudflare R2 Nasıl Çalışır?

R2 içinde veriler bucket adı verilen mantıksal kapsayıcılarda saklanır. Her nesne bucket içinde benzersiz bir object key üzerinden erişilebilir. Uygulamalar Workers binding veya S3 uyumlu endpoint üzerinden nesne okuyabilir ve yazabilir. Upload işlemleri backend, browser veya otomasyon araçları üzerinden gerçekleştirilebilir. Bu yapı R2'yi kullanıcı dosyalarından yedekleme sistemlerine kadar çok farklı iş yüklerinde kullanılabilir hale getirir.

R2 ile Geleneksel Dosya Sistemi Arasındaki Fark

Geleneksel dosya sistemi dizin ve dosya yolları üzerinden çalışır. Object storage ise görünürde klasör benzeri yollar kullansa da temel olarak düz bir key alanına sahiptir. Sunucu diskinde dosyanın bulunduğu fiziksel konumu düşünürken R2 tarafında object key ve erişim politikası daha önemlidir. Birden fazla uygulama instance'ının aynı depolama alanını kullanması da daha kolay hale gelir. Bu nedenle container veya serverless mimarilerde object storage çoğu zaman yerel diskten daha uygun bir tercih olur.

R2 ile AWS S3 Arasındaki İlişki

R2 birçok yaygın S3 API kullanım şekliyle uyumlu çalışacak biçimde tasarlanmıştır. Bu nedenle S3 SDK'leri, CLI araçları ve mevcut entegrasyonların önemli bir bölümü R2 endpoint'i ile kullanılabilir. Yine de iki hizmetin bütün özelliklerinin birebir aynı olduğunu varsaymak doğru değildir. Migration veya SDK geçişinde kullanılan API çağrılarının destek durumunu ayrıca test etmek gerekir. En güvenli yaklaşım, uygulamanın gerçekten kullandığı işlemler üzerinden uyumluluk testi yapmaktır.

S3-Compatible API Ne Anlama Gelir?

S3-compatible API, S3 ekosistemindeki yaygın request formatlarının ve imzalama yöntemlerinin R2 ile kullanılabilmesini ifade eder. Bu sayede AWS SDK, rclone veya S3 uyumlu farklı araçlar için tamamen yeni bir istemci katmanı yazmak gerekmez. Genellikle endpoint ve credential bilgilerini değiştirmek entegrasyonun önemli kısmını oluşturur. Ancak lifecycle, event veya storage class gibi özelliklerin davranışı sağlayıcıya göre farklılık gösterebilir. Production'a geçmeden önce uygulamanızın ihtiyaç duyduğu API yüzeyini test etmeniz faydalıdır.

R2'nin Temel Kullanım Alanları

R2 yalnızca statik görsel saklamak için kullanılmaz. Kullanıcı dosyaları, backup arşivleri, uygulama logları, veri setleri ve build artifact'ları aynı object storage yaklaşımıyla yönetilebilir. Önemli olan her veri türünün retention, erişim ve güvenlik ihtiyacını ayrı değerlendirmektir. Kullanıcı tarafından sık erişilen medya ile yıllık backup arşivinin aynı lifecycle politikasına sahip olması gerekmez. Veri sınıflandırması bucket ve prefix tasarımını da doğrudan etkiler.

Kullanıcı dosyaları

Kullanıcı dosyaları profil görselleri, belgeler, ekler veya yüklenen medya içerikleri olabilir. Bu veriler genellikle kullanıcı kimliği ve erişim yetkileriyle ilişkilidir. Object key üretirken tahmin edilebilir dosya adları yerine güvenli kimlikler kullanmak daha sağlıklıdır. Private erişim varsayılan seçim olmalı, paylaşım gerektiğinde kontrollü URL üretimi değerlendirilmelidir. Silme ve kullanıcı hesabı kapatma süreçleri de storage lifecycle ile birlikte tasarlanmalıdır.

Görseller ve medya

Görsel ve medya dosyaları yüksek trafik ve büyük veri boyutları nedeniyle object storage için doğal kullanım alanıdır. Orijinal dosya ile optimize edilmiş türevleri farklı prefix'lerde saklamak işinizi kolaylaştırabilir. Upload sonrasında thumbnail veya format dönüşümü event-driven pipeline ile başlatılabilir. Public medya sunuluyorsa custom domain ve cache stratejisi origin okuma yükünü azaltabilir. Private medya için ise authorization kontrollü indirme akışı kurulmalıdır.

Backup

Database dump ve sunucu yedekleri R2 üzerinde düzenli olarak saklanabilir. Backup dosyasının yalnızca yüklenmesi yeterli değildir, checksum ve restore testi de yapılmalıdır. Retention süresi iş gereksinimine göre lifecycle kuralına dönüştürülebilir. Kritik yedeklerde encryption ve erişim anahtarı yönetimi ayrıca ele alınmalıdır. Otomasyon başarısız olduğunda alarm üreten bir sistem kurulması backup sürecini güvenilir hale getirir.

Log arşivi

Uzun süre saklanması gereken uygulama logları günlük veya saatlik arşiv dosyalarına dönüştürülebilir. Tarih bazlı object key yapısı belirli döneme ait logları kolay yönetmenizi sağlar. Eski loglar daha seyrek erişilen storage class politikasına taşınabilir. Retention gereksinimi varsa lifecycle ile otomatik silme uygulanabilir. Analiz sistemi object storage içeriğini ayrı veri işleme hattına aktarabilir.

Veri setleri

Büyük veri setleri object storage üzerinde dosya veya parça halinde saklanabilir. Dataset sürümleri key isimlendirmesinde veya ayrı metadata tablosunda takip edilmelidir. Büyük upload işlemleri multipart yaklaşımından faydalanabilir. Verinin hash değeri bütünlük kontrolü ve duplicate tespiti için kullanılabilir. Sık sorgulanacak metadata ise object storage yerine ilişkisel veritabanında tutulmalıdır.

ML model artifacts

Model ağırlıkları, tokenizer dosyaları ve eğitim çıktıları büyük binary artifact örnekleridir. Sürüm bilgisi ve model kimliği object key tasarımında açık biçimde yer alabilir. CI/CD veya eğitim pipeline'ı tamamlandığında dosyalar otomatik olarak R2'ye yüklenebilir. Üretimde kullanılan artifact için erişim izinleri daha dar tutulmalıdır. Konteyner ve AI endpoint yapılandırmalarıyla ilgileniyorsanız https://www.diyarbakiryazilim.com.tr/posts/konteynerize-ai-ag-uc-noktalarinin-endpoints-yapilandirilmasi adresindeki teknik içeriği de inceleyebilirsiniz.

Cloudflare R2'nin Temel Mimari Bileşenleri

R2 mimarisini anlamak, upload kodunu yazmaktan önce gelmelidir. Bucket veriyi gruplarken object gerçek saklanan içeriği temsil eder. Object key, uygulamanın nesneyi nasıl adreslediğini belirler ve çoğu organizasyon kararının merkezinde yer alır. Workers binding ve S3 endpoint ise uygulamanın R2'ye hangi yoldan bağlanacağını belirler. Bu parçaları doğru ayırdığınızda erişim, otomasyon ve maliyet yönetimi çok daha öngörülebilir hale gelir.

Bucket

Bucket bir grup object için mantıksal kapsayıcıdır. Environment, veri türü veya güvenlik sınırı için ayrı bucket kullanabilirsiniz. Bucket sayısını gereksiz artırmak operasyon yükünü yükseltebilir. Buna karşılık farklı erişim politikalarına sahip verileri tek bucket içinde toplamak da yönetimi zorlaştırabilir. Bucket sınırı seçilirken lifecycle ve permission ihtiyaçlarının birlikte düşünülmesi gerekir.

Object

Object, R2 üzerinde saklanan gerçek veri birimidir. İçerik bir görsel, zip arşivi, video veya herhangi bir binary dosya olabilir. Object key üzerinden bulunur ve gerekli olduğunda metadata bilgileriyle desteklenir. Object güncelleme ve silme davranışı uygulamanın iş akışına göre kontrol edilmelidir. Kullanıcı tarafından yüklenen nesnelerde ownership bilgisini ayrı veritabanında tutmak çoğu zaman daha güvenlidir.

Object Key

Object key, bucket içindeki nesnenin benzersiz adresidir. İyi bir key stratejisi tenant izolasyonunu ve operasyonel yönetimi kolaylaştırır. Örneğin tenant, tarih ve UUID bileşimi aynı key içinde kullanılabilir. Original filename'in tek başına key olması collision ve güvenlik sorunları yaratabilir. Key yapısının uygulama büyüdükçe değişmesi zor olacağı için erken tasarım önemlidir.

Metadata

Object metadata dosya hakkında sınırlı ek bilgi taşımak için kullanılabilir. Content type, source veya basit teknik özellikler burada saklanabilir. Kullanıcı yetkisi ve arama gerektiren metadata için veritabanı daha uygundur. Metadata boyutunun ve kullanım amacının kontrol altında tutulması gerekir. Object metadata ile ilişkisel iş verisini birbirine karıştırmamak yönetimi kolaylaştırır.

R2 Gateway

R2 erişimi Cloudflare altyapısı üzerinden object storage operasyonlarına yönlendirilir. Uygulama açısından önemli olan doğru endpoint ve authentication yöntemini kullanmaktır. External backend S3 uyumlu endpoint ile bağlanabilir. Workers içinde ise binding yaklaşımı daha doğal olabilir. Erişim yolunun uygulamanın çalıştığı ortama göre seçilmesi credential yönetimini de sadeleştirir.

Workers Binding

Workers binding, Worker kodunun R2 bucket'a doğrudan platform entegrasyonu üzerinden erişmesini sağlar. Bu yaklaşım ayrı S3 credential yönetme ihtiyacını azaltabilir. Worker içinde put, get veya list benzeri işlemler kullanılabilir. Özellikle upload metadata kontrolü ve private download proxy senaryolarında oldukça pratiktir. External servisler için ise S3 API credential yaklaşımı daha uygun olabilir.

S3 API Endpoint

S3 API endpoint, harici uygulamaların R2'ye S3 uyumlu protokolle bağlanmasını sağlar. AWS SDK, rclone ve benzeri araçlarda bu endpoint tanımlanabilir. Credential bilgileri secret store üzerinden güvenli biçimde verilmelidir. Development ve production ortamlarının farklı endpoint veya credential setleri kullanması önerilir. Yanlış endpoint yapılandırması signature hatalarının yaygın sebeplerinden biridir.

R2 Bucket Yapısı Nasıl Tasarlanmalı?

Bucket tasarımında ilk refleks her şey için ayrı bucket açmak veya bütün veriyi tek bucket içine koymak olabilir. İki uç yaklaşım da zamanla yönetim sorunları oluşturabilir. Environment, tenant ve erişim politikası gerçek ayrım noktaları olarak değerlendirilmelidir. Prefix yapısı birçok mantıksal gruplama ihtiyacını tek bucket içinde çözebilir. Bununla birlikte compliance veya güvenlik sınırı gerektiğinde fiziksel bucket ayrımı daha doğru olabilir.

Tek Bucket mı Çoklu Bucket mı?

Tek bucket operasyonel olarak daha sade olabilir. Prefix kullanarak veri türleri ve tenant'lar ayrılabilir. Çoklu bucket ise farklı erişim anahtarları, jurisdiction veya lifecycle gereksinimlerinde güçlü bir sınır oluşturur. Karar verirken yalnızca object sayısını değil permission ve retention ihtiyaçlarını değerlendirin. Çoğu sistem için birkaç anlamlı bucket ile düzenli prefix yapısı iyi bir dengedir.

Environment Bazlı Bucket

Development, staging ve production verilerinin birbirinden ayrılması güvenli bir pratiktir. Test kodunun yanlışlıkla production dosyalarını silmesi ciddi sonuç doğurabilir. Ayrı bucket kullanmak environment sınırını görünür hale getirir. Credential setleri de her environment için ayrı tutulabilir. Böylece deployment hatalarının etki alanı küçülür.

Development

Development bucket geçici ve test amaçlı veriler için kullanılabilir. Lifecycle süresi production'a göre daha kısa tutulabilir. Geliştirici credential'larının yalnızca bu bucket'a erişmesi önerilir. Test upload'larının düzenli temizlenmesi maliyet ve listeleme yükünü azaltır. Gerçek kullanıcı verilerinin development ortamına kopyalanmaması daha güvenli bir yaklaşımdır.

Staging

Staging ortamı production davranışını test etmek için kullanılır. Bucket policy ve CORS ayarlarının production'a yakın olması faydalıdır. Bununla birlikte credential ve domain bilgileri kesinlikle ayrı tutulmalıdır. Migration ve lifecycle değişiklikleri önce staging üzerinde denenebilir. Bu yaklaşım yanlış silme veya erişim hatalarını production öncesinde görmenizi sağlar.

Production

Production bucket gerçek kullanıcı ve iş verilerini barındırır. Token yetkileri mümkün olduğunca dar tutulmalıdır. Lifecycle ve bucket lock değişiklikleri kontrollü review sürecinden geçmelidir. Cost, object count ve hata oranları düzenli izlenmelidir. Production üzerinde manuel ve plansız değişiklik yapmamak uzun vadede daha güvenli bir operasyon sağlar.

Tenant Bazlı Organizasyon

Multi-tenant sistemlerde object key içine tenant kimliği eklemek güçlü bir düzen sağlar. Örneğin tenants/{tenantId}/... biçimi kullanılabilir. Authorization katmanı kullanıcının yalnızca kendi tenant prefix'i için upload izni almasını sağlamalıdır. Presigned URL üretirken backend key'i kendisi oluşturmalıdır. Client'ın istediği arbitrary key'i kabul etmek tenant izolasyonunu zayıflatabilir.

Veri Türüne Göre Bucket

Backup, public medya ve hassas kullanıcı belgesi farklı retention ihtiyacına sahip olabilir. Bu nedenle bazı sistemlerde veri türüne göre bucket ayrımı anlamlıdır. Özellikle lifecycle ve public access politikaları çok farklıysa yönetim kolaylaşır. Benzer erişim profiline sahip veriler ise prefix ile aynı bucket içinde tutulabilir. Ayrımı gerçek operasyon ihtiyacına göre yapmak gereksiz yapı oluşmasını önler.

Access Policy'ye Göre Bucket

Public ve private verileri ayrı bucket'larda tutmak permission modelini sadeleştirebilir. Private bucket için public domain hiç açılmayabilir. Public medya bucket'ı ise custom domain ve cache ile sunulabilir. Hassas dosyalarda presigned GET veya Worker proxy kullanılabilir. Erişim politikasını bucket sınırında ayırmak yanlış yayınlama riskini azaltır.

R2'de Folder Gerçekten Var mıdır?

Object storage tarafında klasik anlamda fiziksel klasör sistemi bulunmaz. Folder gibi görünen yapı object key içindeki slash karakterleriyle oluşturulan prefix'lerden ibarettir. Bu ayrımı anlamak listeleme ve lifecycle tasarımında önemlidir. Bir klasörü yeniden adlandırmak gerçekte çok sayıda object key değişikliği anlamına gelebilir. Bu nedenle prefix yapısını erken ve stabil biçimde tasarlamak iyi bir fikirdir.

Flat Object Namespace

R2 object'leri temel olarak düz bir namespace içinde key değerleriyle saklar. Slash karakteri görsel organizasyon sağlar ancak gerçek dizin değildir. List operasyonları prefix üzerinden belirli key gruplarını filtreleyebilir. Bu model klasik filesystem hareketlerinden farklı düşünülmelidir. Milyonlarca object bulunan sistemlerde key convention operasyon performansı açısından da önem kazanır.

Prefix Kullanımı

Prefix, object key'in ortak başlangıç bölümüdür. Tenant, veri tipi veya tarih partition'ı oluşturmak için kullanılabilir. Lifecycle rule belirli prefix'e uygulanabilir. Event notification da prefix filtresi üzerinden belirli veri akışlarını ayırabilir. Bu nedenle prefix yalnızca görsel düzen değil otomasyon tasarımının bir parçasıdır.

users/123/images/...

users/123/images/... biçimi belirli kullanıcıya ait görselleri mantıksal olarak gruplar. Listeleme sırasında users/123/images/ prefix'i kullanılabilir. Authorization katmanı user id değerini client'tan körü körüne almamalıdır. Backend doğrulanmış kullanıcı kimliğine göre key üretmelidir. Böylece başka kullanıcının alanına dosya yazılması önlenebilir.

Prefix'in Listeleme ve Lifecycle'daki Rolü

Prefix filtreleri büyük bucket içinde ilgili nesneleri daha kolay yönetmenizi sağlar. Temporary dosyalar tmp/ altında tutulup kısa sürede silinebilir. Logs/ prefix'i farklı storage class politikasına geçirilebilir. Event pipeline yalnızca uploads/images/ ile başlayan object'leri işleyebilir. İyi prefix tasarımı ileride yazacağınız operasyon kodunu ciddi biçimde sadeleştirir.

Object Naming Convention

Object naming convention bütün ekip tarafından anlaşılır ve stabil olmalıdır. Aynı veriyi farklı kod yollarının farklı formatlarda yazması yönetimi zorlaştırır. Tenant, tarih, UUID ve dosya uzantısı gibi bileşenlerin sırası standartlaştırılabilir. Key içine hassas kullanıcı bilgisi yazmamak gerekir. Naming rule dokümante edilip ortak helper fonksiyon üzerinden uygulanabilir.

Sağlam Object Key Stratejisi Nasıl Oluşturulur?

Object key yalnızca dosya yolu değildir, storage sisteminin kimlik modelidir. Collision, güvenlik ve lifecycle davranışı key tasarımından etkilenir. Original filename kullanıcı deneyimi için metadata olarak saklanabilir fakat benzersiz storage kimliği olarak kullanılmamalıdır. UUID, ULID veya content hash gibi bileşenler daha güvenli seçenekler sunar. Tenant ve tarih partition'ı da operasyon ihtiyaçlarına göre key içinde yer alabilir.

Original Filename Kullanmanın Riskleri

Original filename kullanıcı tarafından kontrol edilir. Aynı isim birden fazla upload'da tekrar edebilir. Dosya adı beklenmeyen karakterler veya hassas bilgiler içerebilir. Filename'i doğrudan key yapmak overwrite riskini de artırır. Daha iyi yaklaşım benzersiz key üretip original filename'i ayrı metadata alanında tutmaktır.

UUID

UUID benzersiz object kimliği üretmek için yaygın bir yöntemdir. Tahmin edilmesi zor ve collision riski oldukça düşüktür. Kullanıcı dosyasının adı key üzerinde görünmek zorunda kalmaz. Bununla birlikte UUID tek başına veri türü veya tarih hakkında bilgi vermez. Bu nedenle prefix ile birlikte kullanıldığında daha dengeli bir yapı oluşur.

ULID

ULID benzersiz kimlik üretirken zamansal sıralama avantajı sağlayabilir. Bazı sistemlerde listeleme ve debug sırasında daha okunabilir bir sıra sunar. Key içinde tenant veya veri türü prefix'i ile kullanılabilir. Kimliğin istemci tarafından değil güvenilir backend tarafından üretilmesi daha iyidir. ULID kullanımı uygulamanın bütün storage katmanında tutarlı olmalıdır.

Timestamp

Timestamp key içinde veri oluşum zamanını temsil etmek için kullanılabilir. Tek başına benzersiz kimlik olarak güvenli değildir. Aynı anda birden fazla upload gerçekleşebilir. Tarih partition'ı ile operasyonel fayda sağlarken UUID ile collision problemi çözülebilir. Timestamp formatı timezone ve sıralama davranışı düşünülerek seçilmelidir.

Content Hash

Content hash dosya içeriğinden deterministik kimlik üretir. Aynı içeriğin tekrar yüklenmesini tespit etmek için kullanılabilir. SHA-256 gibi güçlü hash değerleri duplicate kontrolünde yararlıdır. Bununla birlikte kullanıcıların aynı dosyaya erişim hakkı farklı olabilir. Hash tabanlı deduplication yapılırken authorization ve ownership modeli ayrıca korunmalıdır.

Tenant ID

Tenant id object key içine dahil edildiğinde veri sınırı daha görünür hale gelir. tenants/{tenantId}/... biçimi listeleme ve lifecycle yönetimini kolaylaştırabilir. Tenant id doğrudan kullanıcı input'undan alınmamalıdır. Authentication sonucu belirlenen tenant bilgisi kullanılmalıdır. Shared cache ve database kayıtlarında da aynı tenant kimliği korunmalıdır.

Date Partitioning

Date partitioning özellikle log, backup ve yüksek hacimli batch verilerinde faydalıdır. Belirli güne ait object'ler aynı prefix altında gruplanabilir. Retention ve batch işlem job'ları tarih üzerinden daha kolay çalışır. Kullanıcı medyasında tarih partition'ı her zaman gerekli olmayabilir. Key yapısı veri erişim şekline göre belirlenmelidir.

yyyy/mm/dd

yyyy/mm/dd formatı kronolojik ve okunabilir bir prefix yapısı oluşturur. Log arşivi için logs/2026/08/24/... benzeri key'ler kullanılabilir. Lifecycle kuralı doğrudan tarih klasörü üzerinden çalışmasa da prefix organizasyonu operasyon işlerini kolaylaştırır. Yıllar arasında sıralama doğal biçimde korunur. Timestamp ile object oluşum bilgisini karıştırmamak için metadata da tutulabilir.

Human-Readable ve Machine-Readable Key Dengesi

Tamamen rastgele key'ler sistem tarafından kolay yönetilir ama insan incelemesinde bağlam vermez. Aşırı açıklayıcı key'ler ise hassas veri ve değişken format riski taşıyabilir. tenant/type/date/uuid gibi bir yapı iyi denge sağlayabilir. Original filename gerektiğinde son bileşen olarak sanitize edilmiş biçimde eklenebilir. Yine de gerçek kimlik benzersiz ve backend tarafından üretilmiş değer olmalıdır.

R2 Bucket Nasıl Oluşturulur?

Bucket oluşturma işlemi Dashboard, Wrangler veya API üzerinden yapılabilir. Manuel oluşturma başlangıçta kolaydır fakat çoklu environment sistemlerinde configuration-as-code yaklaşımı daha sürdürülebilir olur. Bucket adı deployment süreçlerinde stabil ve öngörülebilir olmalıdır. Production bucket oluşturma yetkisi dar tutulmalıdır. Otomasyon kullanılıyorsa yanlış environment üzerinde işlem yapılmasını önleyen kontroller eklenmelidir.

Cloudflare Dashboard

Dashboard küçük projelerde bucket oluşturmanın en hızlı yollarından biridir. Geliştirici bucket adını ve gerekli seçenekleri görsel arayüzden belirleyebilir. Production operasyonunda manuel değişikliklerin kaydı ayrıca tutulmalıdır. Ekip büyüdükçe configuration drift riski artabilir. Bu nedenle sürekli değişen altyapı ayarları daha sonra kod tabanlı yönetime taşınabilir.

Wrangler

Wrangler Cloudflare projelerini komut satırından yönetmek için kullanılabilir. Worker ve R2 yapılandırmalarını aynı geliştirme akışına dahil etmek kolaylaşır. CI/CD pipeline içinde tekrarlanabilir deployment yapılabilir. Credential bilgileri repository içine yazılmamalıdır. Environment farkları ayrı yapılandırma değerleriyle yönetilmelidir.

Cloudflare API

API üzerinden bucket yönetimi kendi otomasyon sisteminizi geliştirmenizi sağlar. Çok sayıda proje veya tenant altyapısı yöneten ekipler bu yaklaşımı kullanabilir. API token yalnızca gereken yetkilere sahip olmalıdır. Retry ve error handling eklenmeden kritik provisioning işlemleri yapılmamalıdır. Oluşturulan kaynakların merkezi inventory kaydı tutulabilir.

S3-Compatible API

S3-compatible API daha çok object operasyonlarında kullanılır. Uygulamanın hangi bucket management işlemlerinin desteklendiğini ayrıca kontrol etmek gerekir. Object upload ve download akışında S3 SDK oldukça pratiktir. Endpoint ve region benzeri client ayarları R2 beklentilerine göre yapılandırılmalıdır. Migration sırasında yalnızca SDK'nin hata vermemesine değil sonuçların doğruluğuna da bakılmalıdır.

Bucket Name Kuralları

Bucket isimleri stabil ve environment'ı anlaşılır biçimde temsil etmelidir. Production, staging ve development isimlerinin birbirine çok benzemesi operasyon hatasına yol açabilir. İsim içine gizli bilgi koymamak gerekir. Takım içinde ortak naming convention kullanmak deployment kodunu sadeleştirir. İsim kuralları otomasyon içinde validation ile kontrol edilebilir.

Bucket Oluştururken Veri Lokasyonu Nasıl Seçilir?

Veri lokasyonu upload latency, kullanıcı dağılımı ve compliance beklentileri açısından değerlendirilmelidir. Kullanıcıların büyük bölümü belirli coğrafyada bulunuyorsa location hint tercihleri anlamlı olabilir. Bununla birlikte hint yaklaşımının veri yerleşimi konusunda kesin bir hukuk garantisi gibi düşünülmemesi gerekir. Data residency için jurisdiction benzeri daha güçlü kavramlar ayrıca değerlendirilmelidir. Global uygulamalarda performans ve mevzuat ihtiyacı birlikte ele alınmalıdır.

Automatic Location

Automatic location platformun bucket için uygun yerleşim kararını kendisinin vermesine izin verir. Kullanıcı dağılımı tek bir bölgeye bağlı değilse basit bir başlangıç olabilir. Compliance gereksinimi bulunan projelerde otomatik seçim tek başına yeterli olmayabilir. Uygulama ekipleri veri sınıflandırmasını önceden yapmalıdır. Lokasyon kararı production verisi yüklenmeden önce verilmesi daha kolay bir karardır.

Location Hint

Location hint platforma tercih edilen coğrafi yön konusunda ipucu verir. Bu seçenek kullanıcıya yakın storage konumu hedeflenirken faydalı olabilir. Hint ifadesi kesin veri ikamet garantisi olarak yorumlanmamalıdır. Gerçek compliance ihtiyacında jurisdiction politikaları ayrıca incelenmelidir. Performans testleri gerçek upload kullanıcı dağılımıyla yapılmalıdır.

Western Europe

Batı Avrupa ağırlıklı kullanıcı kitlesinde ilgili location hint değerlendirilebilir. Amaç istemci ile depolama yolu arasındaki gecikmeyi azaltmaktır. Büyük dosya upload'larında ağ mesafesi daha görünür hale gelir. Buna rağmen tek başına coğrafya bütün upload performansını belirlemez. ISP, dosya boyutu ve multipart paralelliği de sonucu etkiler.

Eastern Europe

Doğu Avrupa odaklı istemcilerde bölgesel yerleşim performans açısından değerlendirilebilir. Kullanıcıların gerçek dağılımı analytics üzerinden ölçülmelidir. Sadece şirket merkezinin lokasyonuna göre seçim yapmak her zaman doğru sonuç vermez. Mobil kullanıcılar farklı ülkelerden bağlanabilir. Compliance ihtiyacı performans hedefinden bağımsız olarak ayrıca ele alınmalıdır.

Asia-Pacific

Asia-Pacific kullanıcılarının yoğun olduğu projelerde coğrafi yakınlık upload latency açısından önem kazanabilir. Özellikle video veya dataset gibi büyük yüklemelerde RTT etkisi hissedilir. Multipart ve retry stratejisi zayıfsa yalnızca lokasyon seçimi sorunu çözmez. Kullanıcıların nereden upload yaptığı metric olarak izlenmelidir. Global sistemlerde local upload yaklaşımı da değerlendirilmelidir.

Location Hint Bir Garanti midir?

Location hint kavramı bir tercih sinyali olarak ele alınmalıdır. Veri residency şartı olan projelerde bunun tek başına yeterli olduğu varsayılmamalıdır. Hukuki veya sözleşmesel gereksinimler için uygun jurisdiction seçeneği değerlendirilmelidir. Production mimarisi yalnızca performans beklentisine göre tasarlanmamalıdır. Kurumun compliance ekibi storage kararı sürecine dahil edilmelidir.

R2 Jurisdiction Nedir?

Jurisdiction veri residency gereksinimlerinin teknik storage tasarımına yansıtılması için kullanılan önemli bir kavramdır. Belirli veri kategorilerinin belirli coğrafi sınırlar içinde tutulması gerekebilir. Bu ihtiyaç kullanıcıya yakınlık tercihinden farklıdır. Jurisdiction seçimi endpoint ve operasyon süreçleri üzerinde etkili olabilir. Bu nedenle bucket oluşturulmadan önce compliance sınıflandırması yapılmalıdır.

Data Residency

Data residency verinin hangi coğrafi sınırlar içinde saklanacağıyla ilgilidir. Sağlık, finans veya kurumsal sözleşmeler belirli koşullar getirebilir. Bu gereksinim yalnızca storage için değil backup ve log sistemleri için de geçerlidir. Aynı verinin başka servislerde kopyalanması residency politikasını etkileyebilir. Mimari dokümantasyon veri akışının tamamını göstermelidir.

EU Jurisdiction

AB içinde tutulması gereken veri için uygun jurisdiction seçeneği değerlendirilebilir. Bu karar uygulamanın diğer servislerinin de aynı veri sınırına uymasını gerektirebilir. Örneğin processing pipeline başka bölgede çalışıyorsa yalnızca storage sınırı yeterli olmayabilir. Backup ve analytics sistemleri de kontrol edilmelidir. Compliance tasarımı uçtan uca veri hareketini kapsamalıdır.

Jurisdiction ile Location Hint Arasındaki Fark

Location hint daha çok yerleşim tercihi ve performans yönlendirmesi olarak düşünülebilir. Jurisdiction ise veri residency sınırı açısından daha güçlü bir kavramdır. İki seçeneğin amacı aynı değildir. Kullanıcıya yakın storage istemek ile yasal olarak belirli bölge içinde kalmak farklı gereksinimlerdir. Tasarım kararlarında bu ayrım açık biçimde belgelenmelidir.

Jurisdiction Seçiminin API Endpoint'e Etkisi

Jurisdiction kullanılan bucket'a erişim endpoint yapısını etkileyebilir. S3 client oluşturulurken doğru endpoint kullanılmalıdır. Yanlış endpoint authentication veya erişim hatasına dönüşebilir. Environment config içinde jurisdiction bilgisi açık biçimde saklanmalıdır. SDK testleri production öncesinde gerçek bucket ile yapılmalıdır.

Jurisdiction Sonradan Değiştirilebilir mi?

Veri residency kararını sonradan değiştirmek basit bir toggle gibi düşünülmemelidir. Bucket ve içindeki verinin taşınması gereken senaryolar oluşabilir. Bu nedenle ilk tasarımda veri sınıflandırması yapılması önemlidir. Migration gerektiğinde veri bütünlüğü ve kesinti planı hazırlanmalıdır. Compliance açısından değişikliğin etkisi ayrıca değerlendirilmelidir.

R2'ye Dosya Yüklemenin Yolları

R2 upload için tek bir yöntem sunmaz. Dashboard küçük manuel işler için, Wrangler geliştirme için, Workers binding uygulama kodu için ve S3 API harici backend sistemleri için kullanılabilir. Browser upload senaryosunda presigned URL güçlü bir seçenek sunar. Backup ve toplu aktarım için rclone veya AWS CLI gibi araçlar kullanılabilir. En doğru yöntem dosya boyutu, güvenlik ve otomasyon seviyesine göre seçilmelidir.

Dashboard Upload

Dashboard üzerinden manuel upload geliştirme ve hızlı test için uygundur. Küçük sayıda dosyayı denemek için ek kod gerektirmez. Düzenli production upload süreçleri için manuel yaklaşım sürdürülebilir değildir. Hata takibi ve retry mekanizması da sınırlı kalır. Otomatik iş yükleri için CLI veya API tercih edilmelidir.

Wrangler Upload

Wrangler geliştirme ortamında object yönetimini kolaylaştırabilir. Script veya CI sürecine dahil edildiğinde tekrarlanabilir upload yapılabilir. Büyük batch transferlerinde daha özel araçlar tercih edilebilir. Credential güvenliği yine korunmalıdır. Upload sonucu otomasyon tarafından doğrulanmalıdır.

Workers Binding

Worker içinden R2Bucket binding kullanmak server-side upload için doğal bir yöntemdir. Request doğrulandıktan sonra dosya doğrudan bucket'a yazılabilir. Küçük ve orta boy dosyalarda kontrolü backend üzerinde tutmak avantaj sağlayabilir. Büyük dosyalarda Worker üzerinden bütün byte'ları geçirmek daha fazla kaynak tüketebilir. Bu durumda direct browser upload değerlendirilmelidir.

S3 API

S3 API harici backend sistemleri için en esnek yöntemlerden biridir. Node.js, Python, Go ve diğer birçok dilde mevcut SDK kullanılabilir. Endpoint ve credential ayarı R2'ye göre yapılandırılır. Multipart, presigned URL ve object operasyonları bu katman üzerinden yönetilebilir. Uygulama kodunda provider-specific detayları ayrı adapter içinde tutmak taşınabilirliği artırabilir.

AWS SDK

AWS SDK S3 client yapısı R2 ile entegrasyonda kullanılabilir. Client endpoint'i R2 adresine yönlendirilir ve uygun credential sağlanır. Upload, download ve presigned URL üretimi gibi yaygın işlemler tanıdık API üzerinden yapılabilir. Kullanılan özel S3 özelliğinin R2 tarafında desteklendiği test edilmelidir. SDK sürümü ve retry davranışı production standardı olarak sabitlenebilir.

Presigned URL

Presigned URL istemcinin kısa süreli ve sınırlı izinle R2'ye doğrudan erişmesini sağlar. Backend kendi API credential bilgisini browser'a göndermez. URL belirli object key ve operation için üretilir. Büyük kullanıcı upload'larında backend bandwidth ihtiyacını önemli ölçüde azaltabilir. Güvenlik için expiration ve key yetkisi dar tutulmalıdır.

rclone

rclone object storage transferleri için kullanışlı bir komut satırı aracıdır. Backup, migration ve scheduled sync işlerinde değerlendirilebilir. R2 S3 uyumlu endpoint ile remote olarak yapılandırılabilir. Script içinde retry ve loglama seçenekleri kullanılabilir. Sync komutlarının yanlış kullanımı veri silme riski taşıdığı için önce dry-run yaklaşımı uygulanmalıdır.

AWS CLI

AWS CLI S3 uyumlu endpoint üzerinden R2 object işlemleri için kullanılabilir. Endpoint parametresi ve credential bilgileri doğru tanımlanmalıdır. Backup scriptleri veya CI pipeline içinde otomatik upload yapılabilir. Production credential değerleri shell history veya repository içinde bırakılmamalıdır. Komut çıktısı ve exit code monitoring sistemine aktarılmalıdır.

Otomatik Veri Yükleme İçin Hangi Yöntem Seçilmeli?

Cloudflare R2 otomatik dosya yükleme nasıl yapılır sorusunun tek bir cevabı yoktur. Backend kontrollü upload güvenlik ve validation açısından daha fazla kontrol sunarken direct browser upload büyük dosyalarda backend yükünü azaltır. Scheduled backup süreçlerinde CLI veya rclone daha pratik olabilir. Machine-to-machine aktarımda S3 API credential kullanımı doğaldır. Yöntem seçimi trafik profili, dosya boyutu ve hata toleransı birlikte değerlendirilerek yapılmalıdır.

Backend-Controlled Upload

Backend-controlled upload dosyanın önce uygulama sunucusuna gelmesini sağlar. Server authentication, content validation ve business rule kontrolünü upload öncesinde yapabilir. Hassas veya küçük dosyalarda bu model oldukça anlaşılırdır. Ancak dosya byte'ları backend bandwidth ve compute kaynağını kullanır. Büyük medya yüklemelerinde direct upload daha verimli olabilir.

Direct Browser Upload

Direct browser upload dosyayı backend üzerinden taşımadan doğrudan R2'ye gönderir. Backend yalnızca kullanıcıyı doğrular ve kısa ömürlü upload izni üretir. Bu yaklaşım backend bandwidth kullanımını azaltır. Dosya doğrulamasının önemli bir bölümü upload sonrasında event-driven pipeline içinde yapılabilir. Presigned URL güvenliği doğru uygulanmadığında yetkisiz upload riski oluşabilir.

Large File Upload

Büyük dosyalarda multipart upload tercih edilmesi daha dayanıklı bir deneyim sağlar. Dosya parçalara bölünür ve başarısız parça yeniden gönderilebilir. Parallel upload toplam süreyi düşürebilir. Upload session state istemci veya backend tarafından takip edilmelidir. Tamamlanmayan multipart session'ların lifecycle ile temizlenmesi unutulmamalıdır.

Scheduled Batch Upload

Günlük export veya log arşivi gibi işler scheduled batch upload için uygundur. Cron, systemd timer veya CI job belirli zamanlarda upload komutunu çalıştırabilir. Dosya oluşturma, compression, checksum ve upload adımları ayrı loglanmalıdır. Failure alarmı olmadan otomasyon sessizce başarısız olabilir. Retention policy aynı pipeline'ın bir parçası olmalıdır.

Backup Upload

Backup upload genellikle database dump veya filesystem archive üretimiyle başlar. Dosya sıkıştırılabilir ve gerekirse uygulama dışında şifrelenebilir. Ardından R2'ye yüklenir ve checksum doğrulaması yapılır. Lifecycle eski yedeklerin otomatik silinmesini yönetebilir. Gerçek güvenilirlik için belirli aralıklarla restore testi yapılmalıdır.

Machine-to-Machine Upload

Server-to-server veri aktarımında S3 API credential kullanımı daha doğal olabilir. Credential yalnızca gereken bucket ve operation yetkilerine sahip olmalıdır. Machine identity ve secret rotation süreçleri merkezi yönetilmelidir. Büyük dataset aktarımında multipart kullanılabilir. Retry ve idempotency olmadan uzun süreli transferler güvenilir sayılmaz.

Global User Upload

Global kullanıcı kitlesinde network mesafesi upload deneyimini etkiler. Direct upload backend üzerinden dolaşan ek network yolunu azaltabilir. Büyük dosyalarda multipart ve resumability kullanıcı deneyimini ciddi biçimde iyileştirir. Local upload benzeri platform özellikleri de değerlendirilmelidir. Upload latency coğrafi dağılıma göre metric olarak izlenmelidir.

Worker Üzerinden Server-Side Upload

Worker üzerinden upload, request'i doğrulayıp içeriği R2 binding ile yazmak için kullanışlıdır. Backend bütün business rule kontrolünü upload öncesinde uygulayabilir. Metadata ve object key üretimi merkezi biçimde yönetilir. Bununla birlikte büyük dosyaların Worker üzerinden geçirilmesi compute ve latency açısından daha pahalı olabilir. Dosya boyutu arttıkça direct upload yaklaşımını değerlendirmek önem kazanır.

Worker → R2 Binding

Worker kodu environment binding üzerinden R2 bucket'a erişebilir. Ayrı S3 access key taşımak zorunda kalmadan platform içi entegrasyon kullanılabilir. Bu yaklaşım credential yönetimini sadeleştirir. Worker'ın yalnızca gerekli bucket binding'ine sahip olması iyi bir güvenlik sınırıdır. Environment bazlı ayrı binding kullanmak production ve staging ayrımını korur.

R2Bucket.put()

R2Bucket.put() bir object key ve içerik kullanarak veri yazmak için kullanılabilir. Backend key'i kullanıcı input'undan bağımsız güvenli biçimde oluşturmalıdır. Content type ve gerekli metadata bilgilerinin doğru eklenmesi faydalıdır. Hata durumunda database kaydının upload durumuyla nasıl eşleşeceği tasarlanmalıdır. Tek adımlı görünse bile idempotency ihtiyacı unutulmamalıdır.

Authentication

Upload endpoint kullanıcı kimliğini doğrulamadan dosya kabul etmemelidir. Session, token veya başka authentication yöntemi kullanılabilir. Authentication yalnızca kullanıcının kim olduğunu söyler. Hangi tenant veya prefix'e upload yapabileceği authorization ile belirlenmelidir. Public upload endpoint'leri abuse riskine karşı rate limit ile korunmalıdır.

Upload Validation

Dosya boyutu, izin verilen format ve metadata backend tarafından kontrol edilebilir. Client tarafından bildirilen MIME type tek başına güvenilir değildir. Hassas sistemlerde magic byte ve malware scanning eklenebilir. Upload sonrası doğrulama gerektiren dosyalar quarantine prefix'e yazılabilir. Validation başarısızsa object güvenli biçimde silinmelidir.

Metadata Ekleme

Upload sırasında content type ve teknik metadata object üzerinde saklanabilir. Original filename veya uploader id gibi bilgiler uygulama veritabanında tutulabilir. Search edilmesi gereken metadata yalnızca object metadata içine bırakılmamalıdır. Database object key ile business entity arasında ilişki kurabilir. Metadata yapısının versionlanması ileride migration ihtiyacını azaltır.

Backend Üzerinden Geçirmenin Avantajları

Backend upload akışının tamamını kontrol eder. Dosya yazılmadan önce authentication ve validation yapılabilir. Presigned URL mekanizmasına ihtiyaç duyulmaz. Küçük dosyalarda uygulama kodu oldukça basit kalabilir. Ayrıca upload işleminden hemen sonra database transaction benzeri kontrol mekanizmaları kurulabilir.

Dezavantajları

Dosya byte'ları uygulama katmanından geçtiği için backend bandwidth kullanımı artar. Büyük medya upload'larında uygulama instance'ları uzun süre bağlantı tutabilir. Ölçek arttıkça compute ve network maliyeti büyüyebilir. Upload latency istemci, backend ve R2 arasındaki yolun toplamına dönüşebilir. Bu nedenle yüksek hacimli sistemlerde direct upload genellikle daha verimli bir seçenektir.

Memory

Dosyanın tamamını belleğe almak büyük upload'larda ciddi risk oluşturur. Streaming kullanılabiliyorsa memory kullanımı daha kontrollü olur. Framework'ün request body davranışı mutlaka bilinmelidir. Birkaç eş zamanlı büyük upload instance belleğini tüketebilir. Dosya boyutu limiti request işleme başlamadan mümkün olduğunca erken uygulanmalıdır.

CPU

Upload sırasında checksum, compression veya format dönüşümü CPU tüketebilir. Bu işleri request path içinde çalıştırmak latency değerini yükseltebilir. Büyük processing işleri queue üzerinden background consumer'a taşınabilir. Worker veya server kapasitesi upload ve processing yükü arasında ayrılabilir. CPU kullanımı dosya boyutuyla birlikte gözlemlenmelidir.

Latency

Backend proxy modeli ekstra network hop oluşturabilir. Kullanıcı dosyayı önce backend'e, backend ise storage'a taşır. Direct upload bu ikinci yolu ortadan kaldırabilir. Küçük dosyalarda fark sınırlı olabilir. Büyük dosyalarda toplam süre ve timeout riski daha belirgin hale gelir.

Büyük dosya problemi

Büyük dosya tek request içinde backend üzerinden geçtiğinde bağlantı süresi uzar. Network kesintisi bütün upload'ın yeniden başlamasına neden olabilir. Multipart direct upload bu riski azaltır. Backend yalnızca upload session ve yetkilendirme yönetir. Bu model yüksek hacimli video ve dataset uygulamalarında daha dayanıklıdır.

Direct Upload Nedir?

Direct upload, istemcinin dosyayı doğrudan object storage'a göndermesidir. Backend dosyanın kendisini taşımaz, yalnızca upload izni ve object key üretir. Presigned URL bu modelin en yaygın mekanizmalarından biridir. Büyük dosyalarda backend bandwidth ve bağlantı süresi ciddi biçimde azalabilir. Upload tamamlandıktan sonra validation ve processing event-driven pipeline ile devam ettirilebilir.

Browser → R2

Browser kısa ömürlü yetki aldıktan sonra dosyayı doğrudan R2 endpoint'ine gönderebilir. Backend request body içindeki büyük dosyayı hiç görmez. Bu yaklaşım uygulama sunucusunun bandwidth yükünü azaltır. CORS ve presigned URL ayarlarının doğru olması gerekir. Upload tamamlanmadan dosyanın uygulamada aktif kabul edilmemesi daha güvenlidir.

Backend Dosyayı Taşımadan Upload

Backend yalnızca kullanıcı kimliği, dosya metadata'sı ve quota gibi bilgileri kontrol eder. Sonrasında istemciye sınırlı upload izni verir. Dosyanın byte akışı storage'a doğrudan gider. Böylece application server upload proxy görevinden kurtulur. Upload sonrası event veya completion API ile database kaydı güncellenebilir.

Presigned URL

Presigned URL belirli bir object key ve operation için imzalanmış geçici erişim adresidir. Client API credential bilgisini öğrenmez. URL ele geçirilirse expiration süresi boyunca kullanılabileceği için kısa süreli olmalıdır. Backend key ve content policy üzerinde kontrol sağlamalıdır. Kullanıcıya arbitrary bucket erişimi verilmemelidir.

Daha Düşük Backend Yükü

Direct upload backend üzerinden geçen byte miktarını büyük ölçüde azaltır. Uygulama instance'ları daha kısa süre request işler. Yüksek eş zamanlı upload sayısında kapasite avantajı belirginleşir. Backend yalnızca authorization ve metadata işlemlerini yürütür. Bu model compute kaynaklarının asıl business logic için kullanılmasını kolaylaştırır.

Büyük Dosyalarda Avantaj

Büyük dosya upload'ı uzun süreli network bağlantısı gerektirir. Backend proxy modeli timeout ve kaynak tüketimi yaratabilir. Direct multipart upload istemcinin parçaları storage'a göndermesine izin verir. Başarısız part yeniden gönderilebilir. Kullanıcı bağlantısı dalgalı olduğunda bu yaklaşım çok daha iyi deneyim sağlar.

Direct Upload ile Indirect Upload Arasındaki Fark

Direct ve indirect upload arasındaki temel fark dosya byte'larının hangi yoldan geçtiğidir. Indirect modelde backend dosyayı alıp storage'a taşır. Direct modelde backend yalnızca izin üretir ve client storage ile doğrudan konuşur. Güvenlik iki modelde de uygulanabilir fakat kontrol noktaları farklıdır. Dosya boyutu ve traffic büyüdükçe direct modelin operasyonel avantajı artar.

Security

Indirect upload güvenlik kontrolünü tek backend endpoint içinde toplar. Direct upload ise presigned URL'nin scope ve expiration ayarına dayanır. İki modelde de authentication ve authorization gerekir. Direct upload güvenli değildir düşüncesi doğru değildir. Asıl güvenlik, verilen iznin ne kadar dar ve kısa ömürlü olduğuyla ilgilidir.

Validation

Indirect model dosya byte'larını upload öncesinde incelemeye daha uygundur. Direct modelde temel metadata upload izni öncesinde kontrol edilir. Gerçek dosya doğrulaması upload sonrasında queue pipeline içinde yapılabilir. Quarantine prefix bu model için kullanışlıdır. Dosya temiz kabul edilmeden kullanıcıya sunulmamalıdır.

Latency

Indirect upload ekstra backend hop içerir. Direct model client ile storage arasındaki yolu kısaltabilir. Küçük dosyalarda fark önemsiz olabilir. Büyük ve global upload'larda latency farkı daha belirgin hale gelir. Gerçek sonuç kullanıcı bölgelerine göre ölçülmelidir.

Backend Bandwidth

Indirect upload bütün dosya byte'larını backend üzerinden geçirir. Bu durum network kullanımını artırır. Direct upload backend'e yalnızca küçük metadata request'leri gönderir. Büyük medya servislerinde ciddi kapasite tasarrufu sağlar. Monitoring sisteminde backend ingress ve egress değerleri karşılaştırılabilir.

Compute Cost

Backend dosya proxy görevini üstlendiğinde CPU ve connection kaynakları daha uzun süre kullanılır. Direct upload compute kullanımını azaltabilir. Fakat upload sonrası processing yine ayrı compute kaynağı gerektirebilir. Queue tabanlı consumer bu yükü kontrollü biçimde çalıştırır. Maliyet değerlendirmesinde yalnızca storage ücreti değil compute da hesaba katılmalıdır.

Büyük Dosyalar

Büyük dosyalar direct multipart upload için güçlü adaydır. Tek uzun backend request'i hata riskini büyütür. Multipart transfer başarısız parçaları yeniden gönderebilir. Client progress bilgisi daha doğru sunulabilir. Upload cancellation ve resume deneyimi de daha kolay tasarlanabilir.

Hangi Senaryoda Hangisi?

Küçük ve hassas dosyalarda backend-controlled upload sade bir çözüm olabilir. Büyük kullanıcı medyasında direct upload genellikle daha ölçeklenebilir olur. Çok güçlü pre-upload validation gerekiyorsa indirect model tercih edilebilir. Bununla birlikte quarantine ve post-processing direct modelde de güvenli yapı kurulmasını sağlar. Karar gerçek dosya boyutu ve traffic ölçümüne göre verilmelidir.

Presigned URL Nedir?

Presigned URL, API credential bilgisini client'a vermeden sınırlı bir storage işlemi yaptırmanın yoludur. Backend belirli object key, HTTP operation ve expiration bilgisi için URL imzalar. Client bu URL'yi bearer token gibi kullanır. URL başka bir object için otomatik erişim sağlamaz. Doğru uygulandığında direct upload mimarisinin en önemli güvenlik bileşenlerinden biridir.

Geçici Yetkilendirme

Presigned URL kalıcı credential değildir. Belirlenen expiration süresi sonunda kullanılamaz hale gelir. Upload için birkaç dakikalık süre çoğu senaryoda yeterli olabilir. Süre kullanıcı dosya boyutu ve network koşullarına göre seçilmelidir. Gereksiz uzun expiration sızan URL'nin riskini artırır.

API Credential'ı Client'a Vermeden Upload

Access key ve secret hiçbir zaman frontend koduna gömülmemelidir. Presigned URL backend'in kendi credential'ı ile oluşturduğu sınırlı yetkidir. Client yalnızca izin verilen operation'ı yapabilir. Bu model credential sızıntısının etki alanını ciddi biçimde azaltır. Backend yine kullanıcı authorization kontrolünden sorumludur.

Object Key

Presigned URL belirli object key için üretilmelidir. Key backend tarafından oluşturulursa kullanıcı başka tenant alanına yazamaz. Client'a yalnızca filename gönderme hakkı verilebilir. Backend filename'i metadata olarak saklayıp benzersiz key oluşturabilir. Bu yaklaşım object overwrite riskini azaltır.

Operation

İmza belirli HTTP operation için oluşturulur. PUT upload izni veren URL aynı biçimde keyfi DELETE işlemi sağlamamalıdır. İzinleri mümkün olduğunca dar tutmak least privilege yaklaşımını destekler. Download için ayrı GET URL üretilebilir. Backend operation türünü business rule'a göre belirlemelidir.

Expiration

Expiration presigned URL'nin kullanım süresini sınırlar. Çok kısa süre büyük dosyanın upload başlamadan veya tamamlanmadan sorun yaşamasına neden olabilir. Çok uzun süre ise sızan URL'nin kötüye kullanım penceresini büyütür. Dosya boyutu ve istemci bağlantısı dikkate alınmalıdır. Gerekirse upload session yenileme akışı tasarlanabilir.

AWS Signature Version 4

S3 uyumlu presigned URL üretiminde Signature Version 4 imzalama modeli kullanılır. SDK gerekli canonical request ve signature işlemlerini sizin yerinize yapabilir. Manuel imzalama yalnızca özel gereksinim varsa tercih edilmelidir. Sistem saati önemli olduğu için backend clock drift sorunları signature hatasına yol açabilir. SignatureDoesNotMatch hatalarında endpoint, header ve saat bilgisi birlikte kontrol edilmelidir.

Presigned URL ile Direct Browser Upload

Direct browser upload güvenli bir izin oluşturma akışıyla başlamalıdır. Client dosya bilgilerini backend'e gönderir, backend kullanıcıyı doğrular ve güvenli key üretir. Presigned PUT URL döndükten sonra browser dosyayı R2'ye taşır. Upload tamamlanınca event notification veya completion endpoint işlemi başlatabilir. Dosya doğrulama tamamlanmadan business entity'nin aktif duruma alınmaması iyi bir tasarımdır.

1. Client Upload İzni İster

Client filename, size ve content type gibi temel bilgileri backend'e gönderir. Dosyanın kendisi bu request içinde olmak zorunda değildir. Backend bu metadata'yı güvenilir kabul etmemelidir. Quota ve maksimum boyut kontrolü bu aşamada yapılabilir. Uygunsuz request için presigned URL üretilmemelidir.

2. Backend Kullanıcıyı Doğrular

Backend session veya access token üzerinden kullanıcının kimliğini belirler. Ardından upload yetkisi ve tenant sınırı kontrol edilir. Kullanıcının depolama kotası aşılmışsa işlem reddedilebilir. Rate limit de bu endpoint üzerinde uygulanmalıdır. Authorization başarısızsa storage erişimi hiç oluşturulmamalıdır.

3. Backend Object Key Üretir

Object key kullanıcı tarafından doğrudan seçilmemelidir. Backend tenant, tarih ve UUID gibi bileşenlerden key oluşturabilir. Original filename ayrı metadata olarak tutulabilir. Key collision kontrolü gerektiğinde database unique constraint ile desteklenebilir. Üretilen key daha sonra upload record ile ilişkilendirilir.

4. Backend Presigned PUT URL Döndürür

Backend kendi güvenli credential'ı ile kısa süreli PUT URL üretir. URL yalnızca belirlenen object key için geçerli olmalıdır. Expiration süresi makul tutulmalıdır. Gerekli content type veya header koşulları imza davranışıyla uyumlu olmalıdır. Client bu URL'yi yalnızca upload için kullanır.

5. Browser Dosyayı Doğrudan R2'ye Yükler

Browser PUT request ile dosya byte'larını R2'ye gönderir. Backend veri akışının dışında kalır. Progress API kullanılarak kullanıcıya yükleme yüzdesi gösterilebilir. Network hatasında retry politikası uygulanabilir. Büyük dosya threshold aşılırsa multipart akışı kullanılmalıdır.

6. Upload Tamamlanır

HTTP response başarılı olduğunda client upload'ın storage tarafında tamamlandığını bilir. Bu durum dosyanın iş açısından güvenli olduğu anlamına gelmez. Backend completion endpoint'i çağrılabilir. Object HEAD ile doğrulanabilir veya event notification beklenebilir. Processing state database üzerinde uploaded olarak güncellenebilir.

7. Event Notification Tetiklenir

Object create event queue veya consumer pipeline'ını başlatabilir. Consumer dosyanın metadata ve güvenlik kontrollerini yapar. Thumbnail, malware scan veya parsing işlemleri burada çalıştırılabilir. Başarılı processing sonunda dosya active duruma alınır. Event tekrar teslim edilebileceği için consumer idempotent tasarlanmalıdır.

Presigned URL Güvenli midir?

Presigned URL doğru sınırlarla kullanıldığında güvenli direct access sağlayabilir. URL bir bearer token gibi ele alınmalıdır çünkü elinde bulunduran kişi expiration süresi içinde işlemi yapabilir. Bu nedenle URL loglara gereksiz yazılmamalıdır. Key, operation ve süre mümkün olduğunca dar tutulmalıdır. Security modeli presigned URL üretiminden önce yapılan backend authorization kontrolüne dayanır.

Bearer Token Mantığı

Presigned URL possession-based yetki sağlar. URL'yi bilen kişi belirtilen operation'ı gerçekleştirebilir. Ek login prompt beklenmez. Bu nedenle URL hassas veri olarak değerlendirilmelidir. Client analytics veya third-party log sistemlerine URL göndermemek gerekir.

Kısa Expiration Kullanımı

Kısa expiration sızan URL'nin kullanım penceresini daraltır. Küçük dosyada birkaç dakikalık süre yeterli olabilir. Büyük multipart işlemlerinde session tasarımı farklı olabilir. Süre kullanıcı bağlantısının normal koşullarda upload'a başlamasına imkan vermelidir. Gereksiz saatler veya günler süren upload URL'lerinden kaçınılmalıdır.

Tek Object Key

URL yalnızca belirli key üzerinde yetki vermelidir. Kullanıcının prefix içinde istediği key'e yazabilmesi gereksiz risk yaratır. Backend benzersiz key üretmelidir. Böylece başka kullanıcının dosyasını overwrite etme ihtimali azalır. Ownership kaydı database üzerinde ayrıca tutulmalıdır.

Tek Operation

Upload için PUT yetkisi yeterliyse GET veya DELETE izni verilmemelidir. Download gerektiğinde ayrı URL üretilebilir. Operation sınırı saldırı yüzeyini küçültür. Permission model business action ile birebir eşleştirilmelidir. Bu yaklaşım least privilege ilkesinin object storage karşılığıdır.

Content-Type Restriction

Content type upload politikası içinde kontrol edilebilir. Ancak client'ın gönderdiği MIME değerinin gerçek dosya türünü garanti etmediği unutulmamalıdır. Upload sonrası magic byte doğrulaması yapılabilir. Belirli formatlar için allowlist uygulanması daha güvenlidir. Şüpheli dosyalar quarantine alanında tutulmalıdır.

Kullanıcı Bazlı Prefix

Object key user veya tenant prefix'i altında üretilebilir. Bu organizasyon ownership yönetimini kolaylaştırır. Backend doğrulanmış kimliği kullanmalıdır. Client'ın başka user id göndermesi key üretimini değiştirmemelidir. Prefix aynı zamanda lifecycle ve reconciliation job'larında kullanılabilir.

URL Loglarına Dikkat

Presigned URL query string içinde imza bilgileri taşır. Reverse proxy veya analytics sistemi tam URL'yi kaydedebilir. Log retention süresi URL expiration'dan uzun olsa bile hassas veri gereksiz tutulmuş olur. Log sanitization uygulanmalıdır. Support ekranlarına tam presigned URL kopyalamamak iyi bir pratiktir.

Presigned URL ile Hangi İşlemler Yapılabilir?

Presigned URL yalnızca upload için kullanılmak zorunda değildir. Uygun operation için GET, PUT, HEAD veya DELETE erişimi üretilebilir. Her işlem için ayrı business authorization kontrolü yapılmalıdır. Kullanıcıya geniş credential vermek yerine tek işleme özel URL daha güvenlidir. Desteklenmeyen veya daha karmaşık upload akışlarında temporary credential veya backend proxy değerlendirilebilir.

GET

Presigned GET private dosyayı kısa süreli indirme için kullanılabilir. Backend önce kullanıcının object üzerinde okuma yetkisini doğrular. Ardından kısa ömürlü URL üretir. Client dosyayı storage üzerinden doğrudan indirir. Çok hassas içerikte Worker proxy ek kontrol sağlayabilir.

PUT

Presigned PUT direct upload için yaygın yöntemdir. URL belirli object key için oluşturulur. Client dosyayı doğrudan storage'a gönderir. Overwrite istenmiyorsa key'in benzersiz üretildiğinden emin olunmalıdır. Upload tamamlandıktan sonra integrity ve security kontrolü yapılabilir.

HEAD

HEAD request object metadata ve varlık kontrolü için kullanılabilir. Büyük dosyanın tamamını indirmeden durum kontrolü yapılır. Client'a HEAD izni vermek gerektiğinde aynı authorization modeli uygulanmalıdır. Backend upload completion doğrulamasında da kullanabilir. Object exists check tek başına duplicate kontrolünün yeterli yöntemi değildir.

DELETE

Presigned DELETE teknik olarak sınırlı silme erişimi sağlamak için kullanılabilir. Bununla birlikte business uygulamalarında silme işlemini backend üzerinden geçirmek daha kontrollü olabilir. Soft delete ve audit gereksinimleri doğrudan client deletion ile zorlaşabilir. Locked object davranışı da hesaba katılmalıdır. Kritik verilerde delete izni kısa ve açık workflow üzerinden verilmelidir.

Desteklenmeyen Upload Kalıpları

Her S3 upload paterni presigned tek URL modeliyle çözülmeyebilir. Multipart upload birden fazla part ve completion adımı gerektirir. Form tabanlı politikalar veya özel header kombinasyonları ayrıca test edilmelidir. SDK'nin desteklediği özellik ile R2'nin desteklediği özellik aynı varsayılmamalıdır. Production entegrasyonu gerçek dosya boyutlarıyla test edilmelidir.

Presigned URL vs Temporary Credential

Presigned URL tek operation için çok dar yetki sunar. Temporary credential daha geniş bir süre ve API alanı sağlayabilir. Browser'ın çok sayıda object üzerinde işlem yapması gereken özel uygulamalarda geçici credential düşünülebilir. Çoğu basit upload senaryosunda presigned URL daha az yetki verdiği için tercih edilir. Güvenlik modeli kullanıcı ihtiyaçlarına göre seçilmelidir.

Browser Upload İçin CORS Nasıl Yapılandırılır?

Browser doğrudan R2'ye request gönderdiğinde CORS politikası devreye girer. AllowedOrigins yalnızca uygulamanın gerçek domain'lerini içermelidir. Upload için gerekli methods ve headers açıkça tanımlanmalıdır. Wildcard kullanımının gereksiz geniş erişim sağlamamasına dikkat edilmelidir. CORS authentication yerine geçmez ve yalnızca browser davranışını kontrol eder.

AllowedOrigins

AllowedOrigins upload yapmasına izin verilen web origin'lerini belirler. Production domain ve gerekiyorsa staging domain ayrı eklenebilir. Gereksiz wildcard kullanmak origin sınırını genişletir. Development localhost adresi production policy içine bırakılmamalıdır. Origin listesi configuration-as-code ile review edilebilir.

AllowedMethods

Direct upload için PUT gibi gerekli HTTP method'ları açıkça eklenmelidir. Download için GET gerekiyorsa ayrıca tanımlanabilir. İhtiyaç olmayan DELETE gibi method'ları açmamak daha güvenlidir. Preflight request davranışı browser tarafından yönetilir. CORS policy gerçek client akışıyla test edilmelidir.

AllowedHeaders

Client'ın göndereceği content type veya signing ile ilgili header'lar allowlist içine alınabilir. Gereksiz wildcard header kullanımı azaltılabilir. Presigned URL oluşturulurken kullanılan header ile browser request'inin aynı olması önemlidir. Aksi durumda signature uyuşmazlığı görülebilir. Network inspector CORS ve signature hatalarını ayırmak için faydalıdır.

ExposeHeaders

Browser'ın response içindeki belirli header'ları JavaScript üzerinden okuyabilmesi için expose ayarı gerekebilir. ETag gibi upload doğrulamasında kullanılan değerler buna örnek olabilir. Gereksiz header'lar açılmamalıdır. Frontend yalnızca ihtiyaç duyduğu response bilgisini kullanmalıdır. CORS policy minimum yetki yaklaşımıyla hazırlanmalıdır.

MaxAgeSeconds

Preflight response belirli süre browser tarafından cache edilebilir. Bu ayar gereksiz OPTIONS request sayısını azaltabilir. Çok uzun süre policy değişikliklerinin client tarafına geç yansımasına neden olabilir. Development ortamında daha kısa değerler tercih edilebilir. Production değeri kullanım trafiğine göre seçilebilir.

Wildcard Origin Kullanmanın Riskleri

Wildcard origin herhangi bir web sitesinin browser üzerinden endpoint'e request başlatmasına izin verebilir. Presigned URL yine gerekli olsa da attack surface gereksiz genişler. Hassas upload uygulamalarında bilinen domain allowlist daha doğru seçimdir. Development kolaylığı için production güvenliği zayıflatılmamalıdır. CORS ayarı düzenli security review kapsamında kontrol edilmelidir.

CORS Bir Güvenlik Kontrolü müdür?

CORS güvenlik modelinin yalnızca browser tarafındaki bir parçasıdır. Server-to-server request CORS kuralına bağlı değildir. Bu nedenle CORS'u authentication veya authorization yerine koymak ciddi hata olur. Asıl erişim kontrolü backend ve storage credential seviyesinde uygulanmalıdır. CORS yalnızca güvenilir web origin'lerinin browser erişimini yönetmek için kullanılmalıdır.

Browser Enforcement

CORS esas olarak browser tarafından uygulanan bir politikadır. Browser izin verilmeyen cross-origin response'u JavaScript'e açmaz. Komut satırı veya server uygulaması aynı kısıta tabi değildir. Bu nedenle API güvenliği CORS ile sağlanamaz. Authentication her durumda gerekli olmalıdır.

API Authentication'dan Farkı

Authentication request'i yapan kullanıcının kimliğini doğrular. CORS yalnızca browser origin davranışını sınırlar. Kullanıcı geçerli token'a sahip değilse origin doğru olsa bile request kabul edilmemelidir. İki katman farklı sorunları çözer. Production security tasarımında her ikisi de kendi rolünde kullanılmalıdır.

CORS'un Engellemediği İstekler

Server-side script, curl veya özel client CORS kuralına güvenmek zorunda değildir. Saldırgan API endpoint'ine doğrudan request gönderebilir. Bu nedenle rate limit ve authentication şarttır. Presigned URL de kendi signature güvenliğine dayanır. CORS yalnızca istemci tarayıcı deneyimini kontrol eder.

Authentication + Authorization + CORS

Sağlıklı modelde authentication kullanıcıyı tanır. Authorization hangi object üzerinde hangi işlemi yapabileceğini belirler. CORS hangi browser origin'inin request başlatabileceğini sınırlar. Rate limit abuse davranışını kontrol eder. Bu katmanlar birlikte kullanıldığında daha güçlü bir upload güvenliği oluşur.

Upload Endpoint'i Nasıl Güvenceye Alınmalı?

Upload endpoint'i yalnızca dosya kabul eden basit bir route olarak görülmemelidir. Authentication, tenant isolation, quota ve rate limiting aynı endpoint üzerinde değerlendirilmelidir. Dosya boyutu ve format sınırları abuse riskini azaltır. Object key backend tarafından oluşturulmalıdır. Direct upload kullanılsa bile presigned URL üretme endpoint'i bütün bu kontrolleri uygulamalıdır.

Authentication

Upload yapmak isteyen kullanıcının kimliği doğrulanmalıdır. Public anonim upload gerekiyorsa ayrı abuse kontrolleri gerekir. Session veya token süresi upload izin sürecine uygun olmalıdır. Authentication başarısızsa presigned URL üretilmemelidir. Loglarda yalnızca gerekli kullanıcı kimlik sinyalleri tutulmalıdır.

Authorization

Her authenticated kullanıcı her bucket veya prefix'e yazamamalıdır. Kullanıcı rolü, tenant ve business object ilişkisi kontrol edilmelidir. Bir proje dosyasına upload yapılıyorsa kullanıcının projeye erişimi doğrulanmalıdır. Object key backend tarafından bu context'e göre oluşturulmalıdır. Authorization testleri horizontal privilege escalation senaryolarını kapsamalıdır.

Tenant Isolation

Multi-tenant sistemde tenant id güvenilir authentication context'ten alınmalıdır. Client'ın gönderdiği tenant parametresi tek başına kullanılmamalıdır. Key prefix ve database kaydı aynı tenant bilgisini taşımalıdır. Event consumer da tenant sınırını korumalıdır. Reconciliation job farklı tenant verilerini birbirine karıştırmamalıdır.

Rate Limiting

Upload izni üretme endpoint'i yüksek sayıda request ile kötüye kullanılabilir. Kullanıcı, IP veya tenant bazlı rate limit uygulanabilir. Büyük dosya sistemlerinde cost-based quota da düşünülebilir. Rate limit kullanıcı deneyimini bozmayacak gerçekçi sınırlarla seçilmelidir. Aşım olayları security metric olarak izlenebilir.

Upload Quota

Kullanıcının toplam storage kullanımı quota ile sınırlandırılabilir. Upload izni verilmeden önce mevcut kullanım ve yeni dosya boyutu kontrol edilir. Client-reported size daha sonra gerçek object size ile doğrulanmalıdır. Tenant planına göre farklı kota uygulanabilir. Silinen dosyaların quota hesabından ne zaman düşeceği açık olmalıdır.

File Size Limit

Dosya boyutu request'in erken aşamasında kontrol edilmelidir. Presigned URL üretirken bildirilen size ilk filtre olabilir. Upload sonrası gerçek object size ayrıca doğrulanmalıdır. Aşırı büyük dosyalar infrastructure ve maliyet üzerinde baskı oluşturabilir. Farklı file type için farklı limit uygulanabilir.

File Type Allowlist

İhtiyaç duyulmayan dosya türlerini kabul etmemek attack surface'i azaltır. Allowlist yaklaşımı denylist'ten daha güvenilir olabilir. Extension ve MIME tek başına yeterli doğrulama değildir. Magic bytes ve içerik analizi gerektiğinde eklenmelidir. Executable veya script dosyalarının gereksiz kabul edilmemesi önemlidir.

R2 API Token Güvenliği

Cloudflare R2 otomatik yedekleme erişim anahtarı ve bucket güvenliği planlanırken en önemli ilkelerden biri least privilege olmalıdır. Her uygulama aynı geniş token'ı paylaşmamalıdır. Development ve production credential setleri ayrı tutulmalıdır. Secret rotation süreci deployment yapısını bozmayacak biçimde tasarlanmalıdır. Token değerlerinin log, Git ve frontend bundle içine girmemesi temel güvenlik gereksinimidir.

Least Privilege

Token yalnızca uygulamanın gerçekten ihtiyaç duyduğu operasyonlara izin vermelidir. Backup writer yalnızca belirli bucket'a object yazma yetkisiyle çalışabilir. Read ihtiyacı yoksa gereksiz read yetkisi verilmemelidir. Production management yetkisi runtime uygulamasına taşınmamalıdır. Yetki setleri düzenli aralıklarla gözden geçirilmelidir.

Object Read

Yalnızca dosya indiren servis read erişimiyle sınırlandırılabilir. Write veya delete permission eklemek gereksiz risk yaratır. Private object access backend authorization ile birlikte kullanılmalıdır. Token scope mümkünse belirli bucket ile sınırlandırılmalıdır. Read erişim logları hassas sistemlerde ayrıca izlenebilir.

Object Write

Upload worker veya backup job object write iznine ihtiyaç duyabilir. Delete yetkisi aynı token'a otomatik eklenmemelidir. Böylece credential sızsa bile mevcut veriyi silme etkisi azaltılır. Object key prefix politikası uygulama katmanında da korunmalıdır. Write başarısızlıkları monitoring sistemine gönderilmelidir.

Bucket-Scoped Token

Token yalnızca gerekli bucket üzerinde çalışacak biçimde sınırlandırılmalıdır. Bir uygulamanın bütün storage hesaplarına erişmesi gereksizdir. Environment ayrımı bucket scope ile daha güçlü hale gelir. Credential leak durumunda etki alanı küçülür. Yeni bucket eklendiğinde eski token'a otomatik geniş yetki verilmemelidir.

Environment Bazlı Token

Development ve production için farklı credential kullanılmalıdır. Geliştirici bilgisayarındaki token production bucket'a erişmemelidir. CI ve runtime secret store ayrı değerler tutabilir. Staging deployment production credential kullanıyorsa yanlış upload riski oluşur. Environment isolation yalnızca bucket adıyla değil credential ile de uygulanmalıdır.

Secret Rotation

Credential belirli aralıklarla veya şüpheli olay sonrasında değiştirilebilmelidir. Rotation sırasında kesinti yaşamamak için iki credential'ın kısa süre birlikte çalıştığı geçiş modeli kurulabilir. Secret store güncellenip uygulamalar yeniden deploy edilebilir. Eski token iptal edilmeden yeni credential doğrulanmalıdır. Rotation prosedürü incident yaşanmadan önce test edilmelidir.

Token'ı Git'e Koymamak

API token veya secret hiçbir zaman source repository içinde tutulmamalıdır. Private repository bile kalıcı secret storage değildir. Environment secret, CI secret veya güvenli secret manager kullanılmalıdır. Yanlışlıkla commit edilen credential derhal rotate edilmelidir. Git history'den silmek tek başına credential'ı tekrar güvenli hale getirmez.

Workers Binding mi API Token mı?

Workers içinde R2 binding kullanmak çoğu zaman daha sade credential yönetimi sağlar. Harici backend veya CLI ise S3 API token'ına ihtiyaç duyabilir. Her iki yöntemin güvenlik sınırı farklıdır. Binding platform içindeki resource ilişkisinden faydalanırken API token taşınabilir credential niteliğindedir. Uygulamanın çalıştığı ortam hangi yöntemin daha doğal olduğunu belirler.

Workers İçinden Erişim

Worker R2 binding üzerinden bucket'a erişebilir. Secret access key kod içinde bulunmaz. Environment configuration hangi bucket'ın bağlandığını belirler. Bu model deployment ve permission yönetimini sadeleştirir. Worker'ın business authorization kontrolü yine uygulama sorumluluğundadır.

External Backend Erişimi

Cloudflare dışında çalışan backend S3 API üzerinden bağlanabilir. Bu durumda access key ve secret güvenli secret store içinde tutulmalıdır. Network ve retry davranışı SDK tarafından yönetilebilir. Credential rotation süreci ayrı planlanmalıdır. Harici backend için bucket scope sınırı özellikle önemlidir.

Credential Yönetimi

Binding credential detayını uygulama kodundan büyük ölçüde gizler. API token ise environment secret olarak taşınmalıdır. Çok sayıda servis aynı token'ı paylaşmamalıdır. Her workload için ayrı identity daha iyi audit sağlar. Credential inventory tutulması hangi servisin hangi bucket'a eriştiğini görünür kılar.

S3 SDK Uyumluluğu

Harici backend'de S3 SDK kullanmak mevcut kod ekosisteminden faydalanmayı sağlar. Multipart ve presigned URL üretimi daha kolay uygulanabilir. Workers binding ise platforma daha özgü API sunar. İki yaklaşımın kullanım şekilleri aynı olmak zorunda değildir. Ortak business interface ile storage provider ayrıntıları soyutlanabilir.

Güvenlik ve Operasyonel Basitlik

Platform içinde binding çoğu zaman daha az secret yönetimi anlamına gelir. External workload için token kaçınılmaz olabilir. Esas hedef mümkün olan en dar erişimi vermektir. Deployment ve rotation operasyonu ekip tarafından kolay uygulanabilir olmalıdır. En güçlü güvenlik politikası uygulanamadığı için atlanan politika olmamalıdır.

File Upload Validation Nasıl Yapılmalı?

Dosya doğrulama yalnızca extension kontrolünden ibaret değildir. Filename, MIME, magic bytes, boyut ve checksum birlikte kullanılabilir. Zararlı dosya riski varsa malware scanning pipeline eklenmelidir. Direct upload modelinde validation upload sonrasında quarantine alanında çalıştırılabilir. Dosya temiz ve beklenen formatta olduğu doğrulanmadan public kullanıma açılmamalıdır.

Filename Kontrolü

Filename kullanıcı tarafından sağlanan bir girdidir. Path traversal benzeri karakterler storage key üretiminde doğrudan kullanılmamalıdır. Original filename yalnızca görüntüleme amaçlı metadata olarak saklanabilir. Çok uzun veya kontrol karakteri içeren isimler sanitize edilmelidir. Download response oluşturulurken filename header güvenliği ayrıca düşünülmelidir.

Extension

Dosya uzantısı hızlı bir ilk kontrol sağlar. Ancak içerikle uyumlu olduğu garanti edilemez. Zararlı dosya .jpg uzantısıyla gönderilebilir. Bu nedenle extension yalnızca allowlist kararının bir parçası olmalıdır. MIME ve magic byte analiziyle desteklenmelidir.

MIME Type

MIME type browser veya client tarafından bildirilebilir. Bu bilgi kolayca değiştirilebilir. Backend policy için yararlı bir sinyal olsa da tek doğrulama olmamalıdır. Upload sonrası gerçek içerik türü analiz edilmelidir. Response sırasında doğru content type dönmek de güvenlik açısından önemlidir.

Magic Bytes

Birçok dosya formatı başlangıç byte'larında belirli imza taşır. Magic byte kontrolü içerik türünü extension'dan daha güvenilir biçimde anlamaya yardımcı olur. Yine de karmaşık formatlarda tam güvenlik analizi değildir. PDF veya archive gibi formatlarda ek parser kontrolleri gerekebilir. Dosya scanning işlemi izole consumer içinde yapılabilir.

Dosya Boyutu

Dosya boyutu abuse ve maliyet açısından açık sınır gerektirir. Client tarafından bildirilen size yalnızca erken kontrol sağlar. Upload tamamlandıktan sonra gerçek object size doğrulanmalıdır. Büyük dosyalar multipart akışına yönlendirilebilir. Limit plan veya kullanıcı rolüne göre değişebilir.

Checksum

Checksum upload sırasında veri bozulmasını tespit etmeye yardımcı olur. Client dosyanın hash değerini hesaplayabilir. Server veya processing worker object içeriği üzerinden doğrulama yapabilir. Büyük dosyada hash hesaplama CPU maliyeti oluşturur. Güvenilirlik ihtiyacı ile processing maliyeti dengelenmelidir.

Zararlı Dosya Kontrolü

Kullanıcı tarafından yüklenen dosyalar güvenilir kabul edilmemelidir. Özellikle paylaşılabilir belge ve arşivlerde malware scanning değerlendirilebilir. Dosya ilk olarak quarantine prefix'e yazılabilir. Scanner temiz sonucu verdikten sonra güvenli alana taşınır veya metadata active yapılır. Zararlı dosya silinir ve olay security loguna kaydedilir.

MIME Type'a Neden Körü Körüne Güvenilmemeli?

Client-reported Content-Type kullanıcı tarafından değiştirilebilir. Bu nedenle image/png bilgisi dosyanın gerçekten PNG olduğunu garanti etmez. Extension ve MIME birlikte kullanılsa bile içerik doğrulaması gerekebilir. Magic bytes bu noktada önemli ek sinyal sağlar. Güvenlik politikası allowlist ve post-upload scanning ile desteklenmelidir.

Client-Reported Content-Type

Browser upload sırasında MIME bilgisini request header içinde gönderir. Client bu header'ı değiştirebilir. Backend yalnızca bu değere göre güvenlik kararı vermemelidir. Yine de doğru response content type ve UI validasyonu için faydalıdır. Güvenilirlik seviyesi açık biçimde düşük kabul edilmelidir.

Content-Type Spoofing

Saldırgan executable içeriği güvenli bir MIME type ile gönderebilir. Dosya daha sonra yanlış header ile public sunulursa ek riskler oluşabilir. Upload pipeline içeriği bağımsız biçimde doğrulamalıdır. Şüpheli formatlar quarantine'de tutulmalıdır. Public download sırasında Content-Disposition politikası da kullanılabilir.

Magic Byte Validation

Magic byte analizi dosyanın binary imzasını kontrol eder. JPEG, PNG ve PDF gibi formatlarda güçlü bir ilk doğrulama sağlar. Bazı formatlar daha kapsamlı parsing gerektirir. Scanner'ın bütün dosyayı memory içine alması zorunlu değildir. Streaming veya sınırlı byte okuma kullanılabilir.

Allowlist Yaklaşımı

Uygulama yalnızca ihtiyaç duyduğu dosya tiplerini kabul etmelidir. İzin verilmeyen her formatı tek tek engellemeye çalışmak yerine belirli güvenli liste tanımlanabilir. File type, size ve processing rule bu listeyle ilişkilendirilebilir. Yeni format eklemek explicit review gerektirebilir. Bu yaklaşım upload yüzeyini daha yönetilebilir hale getirir.

Zararlı Dosya Upload'ları Nasıl Engellenir?

Malware riskini sıfırlamak yalnızca extension kontrolüyle mümkün değildir. Güvenli pipeline dosyayı önce public olmayan quarantine alanına kabul eder. Event notification scanner consumer'ı tetikleyebilir. Temiz sonuç alınırsa dosya güvenli prefix'e taşınır veya aktif olarak işaretlenir. Enfekte dosya silinir ve olay kayıt altına alınır.

Upload'u Quarantine Prefix'e Alma

Yeni object'ler doğrudan public prefix'e yazılmamalıdır. quarantine/{tenantId}/... benzeri bir alan kullanılabilir. Bu prefix custom domain üzerinden yayınlanmamalıdır. Kullanıcı uygulamasında dosya processing durumda gösterilebilir. Scan tamamlanana kadar indirme izni verilmemelidir.

Event Notification

Object create event scan pipeline'ını otomatik başlatabilir. Event queue üzerinden consumer worker'a iletilebilir. Event tekrar teslim edilebileceği için processing idempotent olmalıdır. Object key ve ETag iş kimliği olarak kullanılabilir. Event kaybolması ihtimaline karşı reconciliation job da değerlendirilebilir.

Malware Scanner

Scanner object'i güvenli işlem ortamında analiz eder. Dosya türüne göre farklı scanning araçları kullanılabilir. Çok büyük dosyalar için streaming yaklaşımı gerekebilir. Scanner timeouts ve error durumları temiz sonuç olarak yorumlanmamalıdır. Başarısız scan dosyayı quarantine durumunda bırakmalıdır.

Clean / Infected Kararı

Processing sonucu database üzerinde açık bir state ile saklanabilir. uploaded, scanning, clean ve infected gibi durumlar kullanılabilir. Kullanıcı yalnızca clean dosyaya erişebilmelidir. Belirsiz veya timeout sonucu infected sayılmak zorunda değildir fakat public olmamalıdır. Manual review akışı gerekli dosya türleri için eklenebilir.

Güvenli Prefix'e Copy

Temiz dosya verified veya public prefix'e taşınabilir. Object storage tarafında bu işlem copy ve eski object deletion şeklinde gerçekleşebilir. Database key güncellemesi atomik olmaya yakın bir workflow ile yönetilmelidir. Copy tamamlanmadan eski object silinmemelidir. Idempotency aynı event'in tekrar işlenmesinde duplicate üretimini önler.

Zararlı Dosyayı Silme

Infected object public erişime açılmamalıdır. Retention veya forensic ihtiyacı yoksa güvenli biçimde silinebilir. Security event logunda hash ve gerekli teknik bilgi tutulabilir. Hassas dosya içeriği loglara yazılmamalıdır. Kullanıcıya teknik scanner ayrıntısı yerine güvenli hata mesajı gösterilebilir.

Dosyanın Bütünlüğü Nasıl Doğrulanır?

Network upload başarılı response döndürse bile kritik sistemlerde veri bütünlüğü ayrıca doğrulanabilir. Checksum client ve server arasında karşılaştırma sağlar. SHA-256 gibi hash değerleri duplicate tespitinde de kullanılabilir. ETag her upload türünde doğrudan content hash anlamına gelmeyebilir. Özellikle multipart upload'da integrity modeli açık biçimde tasarlanmalıdır.

Checksum

Checksum dosya içeriğinden hesaplanan özet değerdir. Upload öncesinde client tarafından üretilebilir. Server işlem sonrasında aynı algoritmayla kontrol yapabilir. Değerler eşleşmiyorsa object bozuk veya yanlış olabilir. Büyük dosyalarda checksum hesaplama süresi upload UX'e göre planlanmalıdır.

ETag

ETag object versiyonunu veya response kimliğini temsil etmek için kullanılabilir. Her durumda dosyanın doğrudan MD5 hash'i gibi düşünülmemelidir. Multipart upload bu varsayımı özellikle geçersiz hale getirebilir. ETag event idempotency için faydalı bir sinyal olabilir. Gerçek content integrity gerekiyorsa ayrı checksum saklamak daha açıktır.

SHA-256

SHA-256 güçlü content hash üretmek için kullanılabilir. Duplicate kontrolü ve integrity doğrulamasında tercih edilebilir. Client-side hesaplama büyük dosyalarda zaman alabilir. Server-side worker veya backend streaming hash hesaplayabilir. Hash değeri database üzerinde object metadata ile birlikte saklanabilir.

Client-Side Hash

Browser dosyayı upload etmeden önce hash hesaplayabilir. Bu değer backend'e metadata request'i içinde gönderilebilir. Aynı hash mevcutsa duplicate kontrolü yapılabilir. Ancak kötü niyetli client hash bilgisini sahte gönderebilir. Güvenlik açısından server-side doğrulama gerektiğinde ayrıca yapılmalıdır.

Server-Side Verification

Processing consumer object içeriğini okuyup hash hesaplayabilir. Bu yöntem client beyanından bağımsız doğrulama sağlar. Büyük object'lerde veri okuma maliyeti hesaba katılmalıdır. Her dosyada tam hash gerekmeyebilir. Kritik backup veya artifact iş akışlarında daha anlamlıdır.

Multipart ETag'in Farklılığı

Multipart upload tamamlandığında ETag değeri basit single-part hash davranışından farklı olabilir. Bu nedenle ETag'i doğrudan SHA veya MD5 olarak yorumlamak güvenli değildir. Uygulama kendi checksum alanını tutabilir. Multipart completion sırasında part bilgileri ayrı saklanabilir. Integrity tasarımı upload yönteminden bağımsız bir kontrat olarak tanımlanmalıdır.

Duplicate Dosyalar Nasıl Önlenir?

Duplicate upload storage maliyetini ve iş kayıtlarının tutarlılığını etkileyebilir. Content hash aynı dosyayı tanımaya yardımcı olur. Idempotency key aynı istemci işleminin tekrar gönderilmesini kontrol eder. Database unique constraint uygulama seviyesindeki race condition riskini azaltır. Object exists check tek başına concurrency altında yeterli olmayabilir.

Content Hash

Aynı içeriğin hash değeri aynı olur. Database üzerinde tenant + hash unique constraint kullanılabilir. Bununla birlikte iki kullanıcının aynı dosyayı paylaşması permission modelini değiştirir. Fiziksel deduplication yapmadan yalnızca duplicate uyarısı vermek daha basit olabilir. Hash hesabının güvenlik ve CPU maliyeti değerlendirilmelidir.

Idempotency Key

Client upload session başlatırken benzersiz idempotency key gönderebilir. Backend aynı key ile tekrar request aldığında yeni object oluşturmak yerine mevcut sonucu döndürebilir. Bu yaklaşım network retry sırasında duplicate kayıt oluşmasını önler. Key kullanıcı veya tenant scope içinde tutulmalıdır. Belirli süre sonra idempotency kayıtları temizlenebilir.

Database Unique Constraint

Application check ile database insert arasında race condition oluşabilir. Unique constraint son güvenlik katmanı olarak duplicate kaydı engeller. Tenant, hash veya business object kombinasyonu kullanılabilir. Constraint violation kontrollü biçimde mevcut upload sonucuna dönüştürülebilir. Storage object ve database transaction sırası ayrıca planlanmalıdır.

Object Exists Check

HEAD veya object metadata kontrolü key'in zaten var olup olmadığını gösterebilir. Ancak iki request aynı anda kontrol edip sonra upload başlatabilir. Bu nedenle exists check tek başına güçlü concurrency garantisi değildir. Benzersiz random key collision ihtimalini zaten çok düşük tutar. Business duplicate kontrolü database seviyesinde daha iyi yönetilebilir.

Aynı Upload'ın Tekrar Gönderilmesi

Mobil network veya timeout nedeniyle kullanıcı aynı dosyayı tekrar gönderebilir. UI retry mekanizması yeni session yerine mevcut session'ı devam ettirebilir. Idempotency key bunun için güçlü araçtır. Multipart upload başarısız part'ı yeniden göndererek bütün dosyanın tekrarını önler. Processing event de idempotent olmalıdır.

R2'de Büyük Dosyalar Nasıl Yüklenir?

Büyük dosya transferlerinde tek PUT her zaman en iyi yöntem değildir. Multipart upload dosyayı parçalara bölerek retry ve resumability sağlar. Video, backup ve dataset gibi dosyalar bu modelden özellikle faydalanır. Parallel part upload toplam süreyi düşürebilir. Buna karşılık session state ve incomplete upload cleanup gibi ek operasyonlar gerekir.

Single PUT

Single PUT dosyanın tek request içinde gönderilmesidir. Küçük ve orta dosyalarda implementation basittir. Network kesilirse request'in tamamının yeniden gönderilmesi gerekebilir. Çok büyük dosyalarda bu kullanıcı deneyimini kötüleştirir. Belirli size threshold üzerinde multipart'a geçmek daha sağlıklı olabilir.

Multipart Upload

Multipart upload dosyayı bağımsız part'lara böler. Her parça ayrı request ile gönderilebilir. Başarısız part tekrar denenirken başarılı part'lar korunur. Son aşamada part numarası ve ETag bilgileriyle upload tamamlanır. Yarım kalan session'lar otomatik temizlenmelidir.

Büyük Video

Büyük video dosyaları mobil ve düşük bant genişlikli bağlantılarda uzun sürede yüklenebilir. Multipart upload kullanıcı bağlantı kesintilerine karşı daha dayanıklıdır. Birkaç part paralel gönderilerek throughput artırılabilir. Çok yüksek paralellik browser ve network üzerinde ters etki oluşturabilir. Upload progress part seviyesinde toplanarak kullanıcıya gösterilebilir.

Backup

Backup arşivleri yüzlerce megabayt veya daha büyük olabilir. Multipart upload uzun transferin yeniden başlamasını önler. Script bütün part state bilgisini güvenli biçimde saklamalıdır. Upload tamamlandıktan sonra checksum ve object size doğrulanabilir. Restore testi yedek otomasyonunun gerçek başarı ölçüsüdür.

Dataset

Dataset dosyaları tek büyük object veya birden fazla partition olarak saklanabilir. Tek büyük dosyada multipart upload faydalıdır. Çok sayıda küçük partition'da operation sayısı maliyeti ayrıca değerlendirilmelidir. Content hash dataset version kontrolünü kolaylaştırır. Metadata ve schema bilgisi ayrı manifest object içinde tutulabilir.

Binary Artifact

Build ve release artifact'ları büyük zip veya binary dosyalar olabilir. CI pipeline multipart upload kullanabilir. Artifact key içinde release version ve commit bilgisi tutulabilir. Retention policy eski build'leri otomatik temizleyebilir. Production release artifact için bucket lock veya daha güçlü erişim politikası düşünülebilir.

Single-Part ve Multipart Upload Arasındaki Fark

Single-part upload implementation açısından daha basittir. Multipart ise büyük dosyada paralellik, retry ve resume avantajı sunar. Hangi yöntemin kullanılacağı size threshold ile otomatik belirlenebilir. Çok küçük dosyayı multipart yapmak gereksiz operation sayısı oluşturur. Çok büyük dosyayı single PUT yapmak ise network hatasında yüksek tekrar maliyeti yaratır.

Dosya Boyutu

Dosya boyutu yöntemi seçmenin temel sinyalidir. Küçük dosyalarda single PUT yeterli olabilir. Büyük dosyalarda multipart daha dayanıklı bir model sağlar. Threshold gerçek kullanıcı network koşullarında test edilmelidir. Tek bir sabit sayı bütün uygulamalar için ideal değildir.

Parallel Upload

Multipart part'ları sınırlı concurrency ile paralel gönderilebilir. Bu yaklaşım kullanılabilir bandwidth'i daha iyi değerlendirebilir. Çok yüksek concurrency connection ve memory tüketimini artırabilir. Mobil cihazlarda daha düşük parallelism tercih edilebilir. Dinamik network koşullarına göre ayar yapmak gelişmiş istemcilerde değerlendirilebilir.

Resumability

Multipart session başarılı part'ların korunmasını sağlar. Network kesildikten sonra yalnızca eksik parçalar gönderilebilir. Bu büyük dosyada ciddi zaman tasarrufu sağlar. Session id ve uploaded part listesi güvenli biçimde tutulmalıdır. Uzun süre devam etmeyen session'lar lifecycle ile temizlenmelidir.

Retry

Single PUT başarısız olduğunda bütün dosya tekrar gönderilebilir. Multipart'ta yalnızca hatalı part yeniden denenir. Exponential backoff ve jitter retry storm riskini azaltır. Permanent 4xx hatalar gereksiz tekrar edilmemelidir. Retry sayısı upload metric olarak izlenmelidir.

Network Failure

Mobil veya uzak bağlantılarda geçici network hataları normaldir. Upload tasarımı bunu istisna değil beklenen durum olarak görmelidir. Timeout ve retry politikasının kullanıcıya açıklanması önemlidir. Multipart session cihaz bağlantısı yeniden geldiğinde devam edebilir. Cancellation kullanıcı isteğiyle network failure durumundan ayrı ele alınmalıdır.

Complexity

Multipart daha fazla client ve backend kodu gerektirir. Session create, part upload ve complete adımları yönetilmelidir. Part ETag bilgileri doğru sırayla saklanmalıdır. Abort ve cleanup akışı da gerekir. Bu ek kod yalnızca gerçekten büyük dosya ihtiyacı varsa kullanılmalıdır.

Multipart Upload Nasıl Çalışır?

Multipart upload önce yeni session oluşturmayla başlar. Dosya belirli part boyutlarına bölünür ve her parça part number ile yüklenir. Başarılı part için dönen ETag bilgisi saklanır. Bütün parçalar tamamlandığında complete request gönderilir. İşlem yarıda bırakılırsa abort çağrısı veya lifecycle cleanup kullanılmalıdır.

CreateMultipartUpload

İlk adım multipart upload session oluşturmaktır. Storage bir upload id döndürür. Bu id sonraki bütün part request'lerinde kullanılır. Backend upload session kaydını kullanıcı ve object key ile ilişkilendirebilir. Session başka kullanıcı tarafından kullanılamamalıdır.

UploadPart

Her dosya parçası ayrı UploadPart request'i ile gönderilir. Part numarası ve upload id request içinde yer alır. Başarılı response ETag döndürür. Client bu ETag değerini completion için saklamalıdır. Aynı part numarasını yeniden göndermek mevcut part'ı değiştirebilir, bu nedenle state yönetimi önemlidir.

Part Number

Part number parçaların mantıksal sırasını belirler. Completion aşamasında doğru ETag ile eşleştirilmelidir. Client part listesini güvenli biçimde tutmalıdır. Parallel upload sırasında completion order ile part order aynı olmayabilir. Son liste dosyanın gerçek sırasına göre oluşturulmalıdır.

ETag

Her başarılı part upload bir ETag bilgisi üretebilir. Client completion request için bunu saklar. ETag'i içerik hash'i gibi kullanmak doğru olmayabilir. Sadece multipart protokolünün gerekli kimliklerinden biri olarak ele alınmalıdır. Retry sırasında yeni ETag geldiyse state güncellenmelidir.

CompleteMultipartUpload

Bütün part'lar yüklendiğinde completion request gönderilir. Part number ve ETag listesi doğru sırada olmalıdır. Başarılı completion sonrasında object normal biçimde kullanılabilir. Processing event bu noktada tetiklenebilir. Database session durumu completed olarak güncellenmelidir.

AbortMultipartUpload

Kullanıcı upload'ı iptal ettiğinde multipart session abort edilebilir. Bu işlem tamamlanmamış part'ların gereksiz storage kullanımını azaltır. Client her zaman abort çağrısını yapamayabilir. Browser kapanması veya network kaybı buna örnektir. Bu nedenle lifecycle cleanup ikinci güvenlik katmanı olarak gereklidir.

Multipart Upload'da Part Size Nasıl Seçilmeli?

Part size çok küçük seçilirse request sayısı ve protocol overhead artar. Çok büyük seçilirse başarısız part'ın yeniden gönderme maliyeti yükselir. Maksimum part sayısı ve object boyutu birlikte düşünülmelidir. Browser memory ve network concurrency de karar üzerinde etkilidir. Gerçek dosya boyutu dağılımına göre dinamik part size kullanmak çoğu sistemde daha iyi sonuç verir.

Minimum Part Size

Multipart protocol belirli minimum parça koşullarına sahip olabilir. Uygulama bu limitleri güncel platform dokümantasyonuna göre doğrulamalıdır. Son part için davranış farklı olabilir. Part size helper fonksiyonu limitleri merkezi biçimde uygulamalıdır. Hard-coded değerler SDK güncellemesi sırasında test edilmelidir.

Maksimum Part Sayısı

Büyük object'lerde part sayısı üst sınırı part size seçimini etkiler. Dosya büyüdükçe parça boyutu da büyütülmelidir. Client upload başlamadan gerekli part sayısını hesaplayabilir. Limit aşılacaksa daha büyük chunk kullanılmalıdır. Bu hesap birim testlerle doğrulanabilir.

Büyük Dosyalarda Part Boyutu

Çok büyük dosyada küçük part sayısı binlerce request üretebilir. Daha büyük part request sayısını azaltır. Buna karşılık tek part retry maliyeti yükselir. Uygun değer ortalama bağlantı hızı ve failure oranına göre seçilebilir. Production upload metric'leri part duration dağılımını göstermelidir.

Parallelism

Parallelism aynı anda kaç part'ın gönderileceğini belirler. Masaüstü hızlı ağda daha yüksek değer kullanılabilir. Mobil bağlantıda düşük concurrency daha stabil sonuç verebilir. Aşırı paralellik browser memory ve bağlantı limitlerini zorlayabilir. Adaptive yaklaşım gerçek throughput üzerinden concurrency ayarlayabilir.

Memory ve Network Dengesi

Her aktif part buffer veya stream kaynağı tüketir. Büyük part ve yüksek concurrency birlikte yüksek memory kullanımı oluşturabilir. Browser crash veya mobile tab kapanması riski oluşabilir. Streaming desteği mümkün olduğunda tercih edilmelidir. Memory profili büyük dosya testlerinde ayrıca ölçülmelidir.

Resumable Upload Neden Önemlidir?

Kullanıcının yüzlerce megabayt dosyayı yeniden başlatmak zorunda kalması kötü bir deneyimdir. Resumable upload yalnızca başarısız parçayı yeniden gönderir. Mobil ağlarda bu özellik daha da önemli hale gelir. Upload session state client ve backend arasında güvenilir biçimde saklanmalıdır. Resume mekanizması dosyanın değişmediğini de doğrulamalıdır.

Başarısız Part'ı Tekrar Göndermek

Multipart upload başarısız part'ı ayrı retry edebilir. Daha önce başarıyla yüklenen parçalar tekrar gönderilmez. Bu durum bandwidth ve kullanıcı zamanından tasarruf sağlar. Retry yeni ETag üretebilir. Completion listesi her zaman en son başarılı part bilgisini kullanmalıdır.

Mobil Ağlar

Mobil cihazlar Wi-Fi ve hücresel ağ arasında geçiş yapabilir. Bağlantı kısa süreli kaybolabilir. Resumable upload bu kesintileri daha iyi tolere eder. UI kullanıcıya upload'ın devam edebileceğini göstermelidir. Session expiration süresi gerçek mobil kullanım senaryosuna uygun olmalıdır.

Büyük Dosyalar

Dosya büyüdükçe upload süresi uzar. Süre uzadıkça network failure ihtimali de artar. Multipart ve resume bu riski parça seviyesine indirir. Çok büyük object için background upload desteği istemci platformuna göre değerlendirilebilir. Kullanıcı kapattığı uygulamaya döndüğünde session tekrar bulunabilmelidir.

Kullanıcı Deneyimi

Kullanıcı progress ve retry durumunu net görmek ister. Upload sıfırdan başlamadığında uygulamaya güven artar. Cancel ve pause seçenekleri büyük dosyalarda faydalıdır. Hata mesajı yalnızca failed demek yerine tekrar denendiğini gösterebilir. Tamamlandı sinyali storage confirmation sonrası verilmelidir.

Upload Session State

Upload id, object key ve part listesi session state içinde tutulur. Client local storage kullanabilir fakat hassas bilgileri dikkatli saklamalıdır. Backend session kaydı kullanıcıyla ilişkilendirilebilir. Session tamamlandığında state temizlenmelidir. Eski session'lar scheduled cleanup ile database'den kaldırılabilir.

Upload Retry Stratejisi

Retry mekanizması her hatayı aynı şekilde tekrar etmemelidir. Geçici network ve 5xx hatalar retry için uygun olabilir. Authentication veya invalid request gibi permanent hatalarda tekrar yapmak anlamsızdır. Exponential backoff ve jitter eş zamanlı client'ların aynı anda yüklenmesini önler. Maksimum retry sınırı ve kullanıcıya hata geri bildirimi mutlaka bulunmalıdır.

Retry Edilebilir Hatalar

Timeout, connection reset veya geçici server hataları retry edilebilir olabilir. 403 gibi authorization hataları genellikle önce düzeltme gerektirir. Hata kodları kategorize edilmelidir. Client rastgele bütün response'ları tekrar göndermemelidir. Metric hangi hata türünün en çok retry ürettiğini göstermelidir.

Exponential Backoff

İlk retry kısa bekleme ile yapılabilir. Sonraki denemelerde bekleme süresi kademeli artırılır. Bu yaklaşım geçici servis baskısını azaltır. Sınırsız büyüyen backoff kullanıcı deneyimini bozabilir. Maksimum delay değeri belirlenmelidir.

Jitter

Jitter retry süresine küçük rastgele fark ekler. Çok sayıda client aynı anda hata aldığında hepsinin aynı saniyede tekrar denemesini önler. Bu durum backend ve storage üzerinde yeni trafik dalgasını azaltır. Jitter özellikle büyük incident durumlarında faydalıdır. Retry library kullanılıyorsa default davranışı kontrol edilmelidir.

Maksimum Retry

Sonsuz retry hem kullanıcıyı hem altyapıyı gereksiz meşgul eder. Belirli deneme sayısından sonra upload failed duruma geçmelidir. Kullanıcı manuel tekrar başlatabilir. Background job için dead-letter benzeri model uygulanabilir. Maksimum retry hata türüne göre değişebilir.

Idempotency

Retry aynı business upload'ı iki kez oluşturmamalıdır. Idempotency key backend session oluşturma aşamasında kullanılabilir. Multipart part retry aynı part numarasını güvenli biçimde tekrar gönderebilir. Completion request tekrar gönderildiğinde beklenen davranış test edilmelidir. Event consumer da duplicate completion olaylarına dayanıklı olmalıdır.

Network Timeout

Timeout dosya ve part boyutuna göre gerçekçi seçilmelidir. Çok kısa süre normal yavaş bağlantıyı hata kabul eder. Çok uzun süre kopmuş bağlantının kaynak tutmasına neden olabilir. Connect ve upload timeout ayrı düşünülebilir. Production latency dağılımı timeout kararını desteklemelidir.

Incomplete Multipart Upload'lar Nasıl Temizlenir?

Başlatılan her multipart upload tamamlanmaz. Kullanıcı browser'ı kapatabilir veya cihaz bağlantısını kaybedebilir. Yüklenmiş part'lar storage alanı tüketmeye devam edebilir. Lifecycle cleanup bu yarım session'ları belirli süre sonra temizlemek için kullanılabilir. Uygulama ayrıca aktif session database kayıtlarını periyodik job ile karşılaştırabilir.

Yarım Kalan Upload'lar

Upload id oluşturulmuş fakat complete çağrısı gelmemiş session yarım kalmış sayılır. Kullanıcı tekrar dönecekse kısa süre korunması faydalı olabilir. Çok uzun süre bırakmak storage israfı oluşturur. Session last activity timestamp tutulabilir. Cleanup politikası gerçek resume kullanımına göre seçilmelidir.

Lifecycle Cleanup

Lifecycle rule incomplete multipart upload'ları otomatik temizlemek için kullanılabilir. Bu özellik manuel cron ihtiyacını azaltır. Kural çok kısa olursa gerçek resumable session'lar erken kaybolabilir. Çok uzun olursa gereksiz storage birikir. Upload session retention ile lifecycle değeri uyumlu olmalıdır.

Default Cleanup Süresi

Platformun varsayılan incomplete upload davranışı zaman içinde değişebileceği için güncel yapılandırma kontrol edilmelidir. Production sistemi default değere körü körüne güvenmemelidir. Gereksinime uygun explicit lifecycle rule daha öngörülebilir olur. Monitoring yarım session sayısını ayrıca gösterebilir. Beklenmeyen artış client bug'ına işaret edebilir.

Özel Lifecycle Kuralı

Upload tipi için ayrı cleanup süresi tanımlanabilir. Örneğin büyük video resume ihtiyacı küçük temp upload'dan daha uzun olabilir. Prefix bazlı lifecycle farklı akışları ayırabilir. Kural deployment öncesinde staging üzerinde test edilmelidir. Production değişikliği review sürecinden geçmelidir.

Storage Waste'i Önlemek

Yarım part'lar kullanıcı tarafından görünmese bile storage tüketebilir. Uzun süre fark edilmezse maliyet birikir. Lifecycle otomatik temizlik sağlar. Metric ve inventory analizi beklenmeyen storage büyümesini tespit eder. Cleanup yalnızca maliyet değil operasyon sağlığı açısından da önemlidir.

Upload Progress Nasıl Gösterilir?

Upload progress özellikle büyük dosyada kullanıcı deneyiminin önemli parçasıdır. Browser gönderilen byte miktarını takip edebilir. Multipart modelde her part'ın ilerlemesi toplam dosya boyutuyla birleştirilmelidir. Retry sırasında progress'in geriye gitmemesi için doğru state hesabı gerekir. Cancel ve tekrar deneme davranışı UI içinde açık biçimde gösterilmelidir.

Browser Progress

Upload client kullanılan API'ye göre progress event alabilir. Gönderilen byte ve toplam size üzerinden yüzde hesaplanabilir. Bazı fetch kullanım şekillerinde upload progress desteği farklı olabilir. Uygun browser API seçilmelidir. UI çok sık render edilmemesi için progress update throttle edilebilir.

Multipart Progress

Her part ayrı progress bilgisi üretir. Toplam uploaded byte bütün aktif ve tamamlanmış part'ların birleşiminden hesaplanır. Retry edilen part eski başarısız byte hesabını yanlış artırmamalıdır. Part state merkezi upload controller içinde tutulabilir. Completion aşaması yüzde 100 öncesinde ayrıca beklenebilir.

Uploaded Bytes

Uploaded bytes kullanıcıya teknik olarak doğru ilerleme bilgisi verir. Yüzde tek başına büyük dosyada kalan süreyi anlatmayabilir. UI örneğin 620 MB / 1.2 GB gösterebilir. Network hızına göre tahmini süre hesaplanabilir. Tahmin sürekli değişebileceği için kullanıcıya kesin süre gibi sunulmamalıdır.

Percentage

Yüzde değeri uploaded bytes / total bytes üzerinden hesaplanır. Multipart concurrency hesabı doğru uygulanmalıdır. Upload tamamlanmadan 100 göstermek kullanıcıyı yanıltabilir. CompleteMultipartUpload response'u beklendikten sonra finished durumu verilmelidir. Processing devam ediyorsa ayrı processing adımı gösterilebilir.

Upload Cancellation

Kullanıcı upload'ı iptal edebilmelidir. Aktif HTTP request'leri abort edilir. Multipart session mümkünse storage üzerinde abort edilir. Backend session durumu cancelled olarak güncellenebilir. Event gelirse cancelled state dikkate alınmalıdır.

Retry Feedback

Geçici hata otomatik retry ediliyorsa kullanıcı bilgilendirilebilir. Sürekli failure durumunda manuel tekrar seçeneği sunulabilir. Hata mesajı teknik signature detaylarını göstermemelidir. Network, yetki ve dosya validation hataları farklı mesajlar alabilir. Support için trace veya upload id kullanıcıya gösterilebilir.

Global Kullanıcılarda Upload Performansı

Global sistemlerde kullanıcı ile storage arasındaki coğrafi mesafe upload hızını etkiler. Büyük dosyada network RTT ve route kalitesi daha görünür hale gelir. Direct upload backend üzerinden geçen ek yolu azaltabilir. Location hint ve local upload seçenekleri doğru kullanımda yardımcı olabilir. Gerçek performans ülke veya bölge bazlı upload latency metric'leriyle ölçülmelidir.

Client ile Bucket Arasındaki Mesafe

Fiziksel mesafe network gecikmesinin önemli bileşenlerinden biridir. Kullanıcı storage'a uzaksa TCP ve request round trip süresi artabilir. Büyük dosyada throughput yalnızca latency'ye bağlı değildir. ISP ve peering kalitesi de önemlidir. Global mimari gerçek kullanıcı ölçümüyle planlanmalıdır.

Network RTT

RTT client ile hedef arasındaki gidiş geliş süresini gösterir. Çok sayıda küçük request yüksek RTT ortamında daha pahalı hale gelir. Multipart part size gereksiz küçük seçilmemelidir. Parallelism bazı gecikme etkilerini azaltabilir. Bununla birlikte aşırı concurrency network verimini bozabilir.

Büyük Dosya Etkisi

Dosya boyutu arttıkça transfer süresi ve failure riski artar. Uzak kullanıcı için resumable upload daha değerli hale gelir. Progress ve retry kullanıcı deneyimini belirgin biçimde etkiler. Direct upload extra backend hop'ını ortadan kaldırır. Büyük dosya performansı küçük test dosyasıyla ölçülmemelidir.

Location Hint

Bucket oluştururken kullanıcı kitlesine yakın coğrafi tercih belirtmek değerlendirilebilir. Hint kesin compliance garantisi değildir. Kullanıcı dağılımı zaman içinde değişebilir. Yeni bölgelere açılan ürünlerde upload latency yeniden ölçülmelidir. Global kullanımda local uploads ek seçenek sunabilir.

Local Uploads

Local uploads verinin istemciye daha yakın noktada kabul edilmesini hedefleyen bir yaklaşımdır. Bu özellik özellikle global upload senaryolarında gecikmeyi azaltabilir. Uygulama tarafında büyük mimari değişiklik gerektirmemesi önemli avantajdır. Jurisdiction sınırlamaları bulunan bucket'larda kullanımı ayrıca değerlendirilmelidir. Production etkisi coğrafi metric'lerle doğrulanmalıdır.

R2 Local Uploads Nedir?

Local uploads, upload işlemini kullanıcının bulunduğu bölgeye daha yakın noktada kabul ederek ilk yazma gecikmesini azaltmayı amaçlar. Veri daha sonra storage yerleşimine arka planda taşınabilir. Uygulama açısından object kısa sürede erişilebilir hale gelir. Özellikle global media veya telemetry sistemlerinde kullanıcı deneyimini iyileştirebilir. Compliance sınırlaması bulunan veri için kullanım uygunluğu ayrıca kontrol edilmelidir.

Veriyi Client'a Yakın Yere Yazma

Client'ın çok uzak storage bölgesine doğrudan uzun ağ yolu kullanması yerine yakın kabul noktası avantaj sağlayabilir. Bu özellikle büyük dosya gönderiminde hissedilebilir. Kullanıcı upload completion süresini daha kısa algılayabilir. Arka plandaki storage yerleşimi platform tarafından yönetilir. Uygulama yine integrity ve processing akışını korumalıdır.

Arka Planda Bucket Bölgesine Replikasyon

İlk upload kabulünden sonra veri bucket'ın kalıcı storage yapısına aktarılabilir. Uygulamanın bu taşıma işini manuel yazması gerekmez. Bu operasyonun veri residency gereksinimleriyle uyumlu olması gerekir. Jurisdiction sınırı varsa özellik desteği ayrıca incelenmelidir. Object processing pipeline aynı object key üzerinden çalışmalıdır.

Object'in Hemen Erişilebilir Olması

Upload tamamlandı sinyali kullanıcının object'e erişim beklentisini belirler. Local upload modelinde object kısa sürede kullanılabilir hale gelebilir. Bununla birlikte security scan tamamlanmadan public erişim açılmamalıdır. Storage availability ile business readiness birbirinden ayrılmalıdır. Database processing state bu farkı temsil edebilir.

Global Upload Latency Azaltma

Global kullanıcıların aynı uzak noktaya upload yapması yüksek gecikme yaratabilir. Local upload bu sorunu azaltmayı hedefler. Kazanç ülke ve network sağlayıcısına göre değişebilir. Production RUM veya client metric'leri gerçek sonucu göstermelidir. Sadece teorik coğrafi yakınlığa dayanarak karar verilmemelidir.

Ek Uygulama Kodu Gerektirmemesi

Platform özelliğinin önemli avantajlarından biri mevcut upload akışını büyük ölçüde koruyabilmesidir. Uygulamanın kendi multi-region upload gateway'ini yazması gerekmez. Bu operasyonel yükü azaltabilir. Yine de feature enablement ve compliance etkisi test edilmelidir. Monitoring önce ve sonra karşılaştırma yapmalıdır.

Local Uploads Ne Zaman Kullanılmalı?

Local uploads en çok coğrafi olarak dağıtık upload istemcilerinde değer üretir. Media, telemetry ve IoT gibi yüksek upload hacmi buna örnektir. Tek bölgede çalışan internal sistemde kazanım sınırlı olabilir. Compliance kısıtı yoksa global latency iyileştirmesi için değerlendirilebilir. Karar ülke bazlı upload metric'leriyle desteklenmelidir.

Global Kullanıcılar

Kullanıcıların farklı kıtalardan dosya gönderdiği uygulamalar güçlü adaydır. Tek storage bölgesine uzak kullanıcılar daha yüksek latency yaşayabilir. Local upload bu farkı azaltabilir. Direct browser upload ile birlikte kullanıldığında backend hop da ortadan kalkar. Büyük dosyalarda etkisi daha belirgin olabilir.

Media Upload

Video ve yüksek çözünürlüklü görseller büyük payload üretir. Kullanıcı uzun upload süresine karşı hassastır. Local upload ve multipart birlikte iyi deneyim sağlayabilir. Upload sonrası transcoding ayrı queue pipeline'a taşınabilir. Media processing tamamlanmadan public URL aktif edilmemelidir.

Telemetry

Dağıtık cihazlardan gelen telemetry batch dosyaları farklı bölgelerden upload edilebilir. Yakın kabul noktası network gecikmesini azaltabilir. Dosyalar tarih ve cihaz prefix'i ile organize edilebilir. Event consumer veriyi analytics pipeline'a aktarabilir. High-frequency küçük object'lerde operation maliyeti ayrıca değerlendirilmelidir.

IoT

IoT cihazları zayıf veya değişken ağ koşullarında çalışabilir. Upload resiliency burada coğrafi yakınlık kadar önemlidir. Retry, checksum ve resumable protocol gerekiyorsa özel client uygulanabilir. Local upload network yolunu kısaltabilir. Device credential güvenliği ayrı attention gerektirir.

Distributed Backup Clients

Farklı ülkelerdeki sunucular merkezi storage'a backup gönderebilir. Büyük arşivlerin uzun mesafeden transferi zaman alır. Local upload başlangıç performansını iyileştirebilir. Backup bütünlüğü checksum ile doğrulanmalıdır. Restore planı storage lokasyonundan bağımsız olarak test edilmelidir.

Cross-Region Upload

Uygulama kullanıcıları bucket yerleşiminden farklı bölgelerde olabilir. Cross-region transfer latency yaratır. Local upload veri kabul noktasını kullanıcıya yaklaştırabilir. Compliance izin veriyorsa bu seçenek değerlendirilebilir. Coğrafi performance dashboard değişikliğin gerçek etkisini göstermelidir.

Local Uploads Ne Zaman Kullanılamaz?

Her storage workload local upload için uygun değildir. Özellikle jurisdiction ile sınırlandırılmış verilerde compliance politikası önceliklidir. Verinin belirli coğrafi sınırı terk etmemesi gerekiyorsa performans optimizasyonu bu gereksinimi ihlal etmemelidir. Storage özelliğinin güncel destek koşulları production öncesinde doğrulanmalıdır. Legal ve security ekipleri veri residency kararına dahil edilmelidir.

Jurisdiction-Restricted Buckets

Jurisdiction belirli veri sınırı gerektiriyorsa local upload özelliğinin bu sınırla uyumu kontrol edilmelidir. Performans uğruna veri residency şartı zayıflatılmamalıdır. Bucket type ve endpoint ayrı olabilir. Uygulama configuration içinde jurisdiction bilgisi açık tutulmalıdır. Test environment production compliance davranışını temsil etmelidir.

Data Residency Gereksinimleri

Data residency teknik olmayan sözleşmesel yükümlülük de olabilir. Storage, processing ve backup kopyalarının tamamı değerlendirilmelidir. Kullanıcı verisi farklı bölgedeki malware scanner'a gönderiliyorsa yalnızca bucket sınırı yeterli değildir. Veri akış diyagramı bu hareketleri görünür hale getirir. Architecture review sırasında her downstream sistem işaretlenmelidir.

Performance ile Compliance Arasındaki Denge

Daha düşük latency önemli olsa da compliance zorunluluğunun önüne geçemez. Alternatif olarak aynı jurisdiction içindeki upload optimizasyonları kullanılabilir. Part size ve direct upload ayarları yine performans sağlayabilir. Kullanıcının gecikmesi metric olarak izlenip farklı çözümler denenebilir. Karar teknik, hukuki ve operasyonel ekiplerin ortak değerlendirmesiyle verilmelidir.

Upload Sonrası Otomasyon Nasıl Kurulur?

Upload tamamlandığında asıl iş çoğu projede yeni başlar. Object create event, queue ve consumer worker kullanılarak processing pipeline oluşturulabilir. Thumbnail, scan, parse veya database update gibi işlemler request path dışına çıkarılır. Bu mimari kullanıcıya hızlı upload response verirken ağır işlerin kontrollü çalışmasını sağlar. Consumer idempotent ve retry destekli tasarlanmalıdır.

Object Create Event

Yeni object oluşturulduğunda event üretilebilir. Event object key, action ve ilgili metadata bilgilerini taşıyabilir. Consumer hangi pipeline'ın çalışacağını prefix üzerinden belirleyebilir. Aynı object için event tekrar gelebileceği varsayılmalıdır. Event işleme sonucu database status ile kaydedilmelidir.

R2 Event Notification

R2 event notification object lifecycle değişikliklerini downstream sistemlere iletebilir. Create ve delete gibi olaylar otomasyon tetikleyicisi olabilir. Queue kullanımı event producer ile processing consumer'ı birbirinden ayırır. Consumer geçici hata yaşasa bile event tekrar denenebilir. Monitoring queue lag ve failure rate değerlerini göstermelidir.

Cloudflare Queue

Queue upload request'i ile processing worker arasında buffer görevi görür. Ani trafik artışı consumer kapasitesini hemen aşmak zorunda kalmaz. Retry ve dead-letter yaklaşımı hata yönetimini kolaylaştırır. Message payload içine gereksiz hassas veri eklenmemelidir. Object key consumer'ın veriyi R2'den çekmesi için genellikle yeterlidir.

Consumer Worker

Consumer message alıp object üzerinde gerekli işlemi çalıştırır. File validation, image processing veya metadata çıkarma burada yapılabilir. İş tamamlandığında database state güncellenir. Aynı event tekrar gelirse sonuç ikinci kez üretilmemelidir. Processing süresi ve hata oranı metric olarak izlenmelidir.

External HTTP Consumer

Bazı processing işleri Cloudflare dışında çalışan servise gönderilebilir. Queue consumer harici API çağrısı yapabilir. Timeout ve retry kontrolü gerekli olur. Harici servis idempotency key kabul ediyorsa object key ve ETag kullanılabilir. Data residency ve privacy etkisi ayrıca değerlendirilmelidir.

R2 Event Notifications Nedir?

Event notifications object üzerinde gerçekleşen belirli işlemlerden sonra otomatik workflow başlatmaya yarar. Create ve delete olayları farklı consumer'lara yönlendirilebilir. Prefix ve suffix filtreleri gereksiz event işleme yükünü azaltır. Multipart completion normal upload completion workflow'una bağlanabilir. Lifecycle tarafından yapılan silme ile kullanıcı silmesini gerektiğinde ayrı kategoride takip etmek faydalıdır.

object-create

Yeni object oluşturma olayları processing pipeline'ın temel tetikleyicisidir. Upload kaynağı direct browser veya backend olabilir. Consumer object key üzerinden dosyayı açar. Scan veya thumbnail gibi işlemleri çalıştırır. Event duplicate delivery ihtimaline göre idempotent işlenmelidir.

object-delete

Delete event metadata senkronizasyonu için kullanılabilir. Database kaydı beklenmeyen object silinmesini fark edebilir. Audit veya reconciliation sistemi olay kaydı tutabilir. Silme zaten database tarafından başlatılmışsa event ikinci delete işlemi oluşturmamalıdır. Event source bilgisi varsa workflow kararında kullanılabilir.

PutObject

PutObject yeni veya güncellenen nesne oluşturabilir. Event consumer overwrite senaryosunu göz önünde bulundurmalıdır. Aynı key yeni içerikle değiştiyse ETag farklı olabilir. Processing sonucunun eski versiyona ait olmaması gerekir. Benzersiz immutable key kullanmak bu sorunu azaltır.

CopyObject

CopyObject quarantine'den verified prefix'e taşıma akışında kullanılabilir. Copy sonrasında yeni event oluşması olasıdır. Consumer event loop oluşturmamak için source ve destination prefix'lerini ayırmalıdır. Verified prefix event'i farklı consumer'a yönlendirilebilir. Copy tamamlandıktan sonra eski object kontrollü biçimde silinir.

CompleteMultipartUpload

Multipart dosya ancak completion sonrasında normal object olarak kabul edilmelidir. Event bu aşamada processing pipeline'ı başlatabilir. Part upload event'lerinin dosya processing tetiklemesi gereksizdir. Database session completed duruma geçer. Checksum ve size doğrulaması bu noktada yapılabilir.

DeleteObject

Explicit object deletion iş veritabanıyla senkronize edilmelidir. Delete event bunun için güçlü bir sinyal olabilir. User-initiated delete ile admin cleanup farklı audit bilgisi taşıyabilir. Soft delete kullanılıyorsa object fiziksel olarak hemen silinmeyebilir. Event workflow'un business delete modeliyle uyumlu olması gerekir.

LifecycleDeletion

Lifecycle tarafından otomatik silinen object'ler de uygulama metadata'sını etkileyebilir. Database hâlâ object var sanıyorsa broken link oluşabilir. Event consumer ilgili kaydı expired duruma çekebilir. Retention policy business database'e de yansıtılmalıdır. Lifecycle değişikliği bu nedenle yalnızca storage ekibinin kararı olmamalıdır.

Event Notification Filtreleri

Her object event'ini aynı consumer'a göndermek gereksiz processing maliyeti oluşturabilir. Prefix ve suffix filtreleri event'i ilgili pipeline ile eşleştirir. images/ altındaki .jpg dosyaları image worker'a yönlendirilebilir. documents/ altındaki PDF'ler farklı parser kullanabilir. Filtre yapısı object key convention ile birlikte tasarlanmalıdır.

Prefix

Prefix event'in hangi key grubunda çalışacağını belirleyebilir. uploads/images/ örneği görsel pipeline'ını izole eder. Backup event'lerinin image worker'a gitmesi engellenir. Prefix değişikliği deployment review gerektirmelidir. Naming convention bozulursa event pipeline sessizce çalışmayabilir.

Suffix

Suffix belirli file extension veya key sonuna göre filtreleme sağlayabilir. .jpg veya .pdf gibi değerler kullanılabilir. Ancak security validation suffix'e güvenmemelidir. Filtre yalnızca routing optimizasyonudur. Gerçek content type yine processing consumer tarafından doğrulanmalıdır.

images/

images/ prefix'i bütün görsel upload'larını tek pipeline altında toplayabilir. Thumbnail ve image optimization consumer'ı buradan beslenebilir. Original ve derivative dosyalar farklı alt prefix kullanabilir. Döngüsel processing olmaması için generated/ alanı event dışında tutulabilir. Object key standardı bütün uploader'lar tarafından aynı uygulanmalıdır.

.jpg

.jpg suffix'i yalnızca routing kolaylığı sağlar. Kullanıcı dosya extension'ını değiştirebilir. Consumer magic byte ile gerçek JPEG olup olmadığını kontrol etmelidir. Uygun değilse dosya quarantine'de kalır. Bu ayrım event routing ile security validation'ı birbirinden ayırır.

Belirli Veri Türleri İçin Ayrı Pipeline

Image, PDF ve video farklı CPU ve tool ihtiyaçlarına sahiptir. Ayrı queue ve consumer kullanmak kapasite izolasyonu sağlar. Video processing yavaşlasa bile image pipeline etkilenmez. Her consumer kendi retry ve dead-letter politikasına sahip olabilir. Bu yaklaşım operasyonel gözlemlenebilirliği de kolaylaştırır.

R2 → Queue → Worker Mimarisi

R2, Queue ve Worker üçlüsü upload sonrasında event-driven processing için net bir model sunar. Object create olayı queue message üretir. Consumer worker message'ı alır ve gerekli işlemi yapar. Sonuç database veya yeni object olarak kaydedilir. Bu akış request path'i kısa tutarken yoğun processing yükünü kontrol altına alır.

Upload

Kullanıcı veya backend object'i R2'ye yazar. Bu aşama yalnızca storage kabulünü ifade eder. Dosyanın business kullanımına hazır olduğu anlamına gelmez. Database state uploaded olarak tutulabilir. Event processing sonucu daha sonra active durumuna geçer.

Event

Object create event upload ile processing arasında sinyal üretir. Event payload mümkün olduğunca küçük olmalıdır. Object key ve gerekli action bilgisi yeterli olabilir. Event duplicate gelebilir. Consumer aynı işi tekrar etmeye karşı korunmalıdır.

Queue

Queue burst traffic'i consumer kapasitesinden ayırır. On bin upload kısa sürede gelse bile processing kontrollü hızda devam edebilir. Queue lag kullanıcıya processing süresi olarak yansır. Lag alarmı capacity ihtiyacını gösterir. Message retention ve retry ayarı processing süresine uygun olmalıdır.

Consumer

Consumer message'ı alıp object'i işler. İşlem başlamadan processing status kontrol edilebilir. Aynı ETag daha önce tamamlandıysa message ack edilebilir. External service çağrısı varsa timeout uygulanmalıdır. Hata durumunda message retry politikasına bırakılır.

Processing

Processing işlemi file type'a göre değişir. Image resize, PDF parse veya malware scan yapılabilir. Ağır işler ayrı servis kullanabilir. Processing süresi p95 metric olarak izlenmelidir. Çok uzun işler queue timeout modeline göre bölünebilir.

Result

İşlem sonucu yeni derivative object veya database metadata olabilir. Thumbnail farklı prefix altında yazılabilir. Parse sonucu searchable metadata tablosuna kaydedilebilir. İşlem tamamlandı sinyali kullanıcı uygulamasına yansıtılabilir. Sonuç idempotent şekilde üretilmelidir.

Metadata Update

Database object state processing'den active durumuna güncellenebilir. Extract edilen width, height veya page count saklanabilir. Object key ve ETag kayıtla ilişkilendirilir. Hata durumunda failed status tutulabilir. UI bu state üzerinden kullanıcıya doğru durumu gösterir.

Upload Sonrasında Otomatik Hangi İşlemler Yapılabilir?

Upload sonrası otomasyon yalnızca thumbnail üretmekle sınırlı değildir. Image optimization, video processing, PDF parsing, malware scan ve database update aynı event-driven modelle çalışabilir. İşlemleri request path dışına taşımak upload yanıtını hızlandırır. Her pipeline ayrı queue kullanarak capacity isolation sağlayabilir. Sonuçların idempotent ve gözlemlenebilir olması production güvenilirliği açısından önemlidir.

Thumbnail Oluşturma

Yeni görsel upload edildiğinde küçük thumbnail üretilebilir. Orijinal object değiştirilmeden derivative key oluşturulur. Aynı object için event tekrar gelirse duplicate thumbnail üretmemek gerekir. Width ve quality değerleri central config içinde tutulabilir. Thumbnail public cache ile hızlı sunulabilir.

Image Optimization

Görseller farklı format veya boyutlara dönüştürülebilir. Kullanıcının yüklediği orijinal dosya arşiv olarak saklanabilir. Web için daha küçük derivative dosyalar üretilir. Processing maliyeti upload request'inden ayrılır. Kullanım sıklığına göre derivative lifecycle politikası uygulanabilir.

Video Processing

Video transcoding CPU açısından ağır bir iştir. Queue worker harici media processing servisini tetikleyebilir. Job id database üzerinde saklanabilir. Tamamlanınca yeni video artifact'ları R2'ye yazılır. Kullanıcı processing state'i polling veya notification ile görebilir.

PDF Parsing

PDF upload sonrası text ve metadata çıkarılabilir. Parser izole ortamda çalıştırılmalıdır. Büyük veya bozuk PDF timeout'a karşı korunmalıdır. Sonuç relational veya search database'e yazılabilir. Original PDF private object olarak kalabilir.

OCR

Tarama görsellerinden metin çıkarmak için OCR pipeline kullanılabilir. İşlem yüksek CPU veya harici servis gerektirebilir. Queue job'ın güvenilir çalışmasını sağlar. OCR çıktısı object metadata yerine searchable database'de tutulabilir. Hassas belge içeriği üçüncü taraf servise gönderiliyorsa privacy değerlendirmesi yapılmalıdır.

AI Classification

Dosya içeriği kategorize etmek için model inference kullanılabilir. Processing consumer ilgili AI endpoint'e güvenli istek gönderebilir. Model sonucu user-generated content moderation veya arama özelliğinde kullanılabilir. Hassas içerik loglara yazılmamalıdır. Model hataları dosyanın storage bütünlüğünü etkilememelidir.

Virus Scanning

Yeni dosya public olmadan önce malware scanner çalıştırılabilir. Scanner sonucu temiz değilse object quarantine'de kalır. Timeout clean sonucu olarak kabul edilmemelidir. Infected object otomatik silinebilir veya forensic policy'ye göre saklanabilir. Scan sonucu database üzerinde audit edilebilir.

Database Update

Processing tamamlandığında object record güncellenebilir. Boyut, hash, processing state ve derivative key'ler kaydedilebilir. Database update başarısız olursa event retry edilebilir. Aynı update ikinci kez geldiğinde duplicate oluşturmamalıdır. Transaction sınırı iş akışına göre belirlenmelidir.

Notification Gönderme

Uzun processing işi tamamlandığında kullanıcıya notification gönderilebilir. Email, push veya in-app event kullanılabilir. Aynı processing event tekrar geldiğinde iki notification gönderilmemelidir. Notification state ayrı idempotency kaydı tutabilir. Kullanıcıya storage teknik ayrıntısı yerine anlaşılır işlem sonucu sunulmalıdır.

Event-Driven Pipeline'da Idempotency

Queue sistemlerinde event'in birden fazla kez teslim edilebilmesi normal kabul edilmelidir. Consumer aynı object üzerinde aynı işlemi tekrar yapınca duplicate sonuç üretmemelidir. Object key ve ETag birlikte processing kimliği olarak kullanılabilir. Database unique constraint veya lock ek koruma sağlar. Idempotency yalnızca upload session değil bütün processing pipeline boyunca korunmalıdır.

Event'in Tekrar Teslim Edilebilmesi

Consumer başarıyla işlem yapıp ack gönderemeden bağlantı kaybedebilir. Queue message'ı yeniden teslim edebilir. Bu durum hata değil dağıtık sistem davranışıdır. Kod ikinci teslimatta mevcut processing sonucunu bulmalıdır. İş zaten tamamlandıysa tekrar maliyetli işlem yapılmamalıdır.

Object Key + ETag

Object key aynı kalırken içerik overwrite ile değişebilir. ETag yeni content version için ek kimlik sinyali sağlar. Processing record key + ETag kombinasyonunu unique tutabilir. Böylece eski ve yeni object versiyonları ayrılır. Immutable key kullanımı sistemi daha da sadeleştirebilir.

Processing Status

Database queued, processing, completed ve failed gibi durumlar tutabilir. Consumer işlem başlamadan mevcut status kontrol eder. Completed kaydı varsa duplicate event ack edilir. Stale processing state için timeout ve recovery job gerekebilir. State geçişleri atomic update ile korunmalıdır.

Database Lock

İki consumer aynı object event'ini eş zamanlı alabilir. Row lock veya conditional update yalnızca birinin processing sahibi olmasını sağlar. Uzun transaction açmak yerine lease benzeri yaklaşım da kullanılabilir. Lock süresi processing süresine uygun olmalıdır. Crash sonrası lock recovery mekanizması bulunmalıdır.

Aynı Dosyayı İki Kez İşlememek

Video transcoding veya OCR gibi işler pahalı olabilir. Duplicate processing doğrudan compute maliyeti yaratır. Processing key unique constraint ile korunabilir. Consumer önce sonucu kontrol edip sonra işe başlamalıdır. External API de idempotency key destekliyorsa aynı kimlik aktarılabilir.

Queue Retry ve Dead-Letter Queue

Her processing hatası kalıcı değildir. Geçici network veya downstream problemi retry ile çözülebilir. Belirli deneme sayısından sonra sürekli başarısız message dead-letter queue'ya taşınabilir. Bu alan manual recovery ve incident analizi için kullanılır. Retry ve DLQ olmadan event pipeline sessiz veri kaybı yaşayabilir.

Temporary Failure

Harici service timeout geçici hata olabilir. Consumer hemen permanent failure işaretlememelidir. Hata türü kategorize edilmelidir. Retry edilebilir durum queue politikasına bırakılır. Kullanıcı processing durumunu pending olarak görebilir.

Retry

Queue message belirli gecikmeyle tekrar teslim edilebilir. Consumer idempotent olduğu için retry güvenli olur. Exponential backoff downstream servisin toparlanmasına zaman tanır. Her retry attempt metric olarak kaydedilebilir. Çok yüksek retry oranı incident sinyalidir.

Max Attempts

Sonsuz deneme poison message'ın sistemi sürekli meşgul etmesine neden olur. Maximum attempt değeri belirlenmelidir. Limit aşıldığında message DLQ'ya geçebilir. Database state failed olarak güncellenebilir. Kullanıcı gerekli olduğunda yeniden processing başlatabilir.

Dead-Letter Queue

DLQ sürekli başarısız event'leri ana pipeline'dan ayırır. Operasyon ekibi hata nedeni üzerinde çalışabilir. Message object key ve error category içerebilir. Hassas dosya içeriği message içine yazılmamalıdır. Recovery sonrası message kontrollü biçimde yeniden kuyruğa alınabilir.

Manual Recovery

Bazı hatalar insan müdahalesi gerektirir. Admin aracı object processing durumunu gösterip retry başlatabilir. Aynı işin zaten tamamlanıp tamamlanmadığı tekrar kontrol edilmelidir. Recovery işlemi audit log üretmelidir. Manuel adım kalıcı çözüm yerine incident yönetimi olarak görülmelidir.

Upload Event'leri Nasıl Loglanır?

Upload logları incident ve audit incelemesinde değerli bilgiler sağlar. Object key, size, action ve timestamp temel alanlardır. Credential veya presigned URL gibi hassas veriler loglanmamalıdır. Yüksek hacimli loglar ayrı storage veya log platformuna gönderilebilir. Retention süresi güvenlik ve maliyet ihtiyacına göre belirlenmelidir.

Object Key

Object key işlemin hangi nesne üzerinde olduğunu gösterir. Key içinde hassas kişisel bilgi bulunmaması log güvenliğini artırır. Tenant prefix incident analizini kolaylaştırabilir. Log aggregation key'i searchable field olarak tutabilir. Public support logunda tam key gerektiğinde maskelenebilir.

Size

Object size upload pattern'lerini anlamaya yardımcı olur. Anormal büyük dosyalar abuse veya client bug gösterebilir. Histogram metrikleri logdan daha uygun olabilir. Tenant bazlı storage quota hesabında size kullanılır. Client beyanı yerine gerçek storage object size tercih edilmelidir.

ETag

ETag object versiyonunu ayırt etmek için yararlı olabilir. Processing logları aynı key'in farklı content versiyonlarını ayırabilir. ETag'i doğrudan cryptographic checksum gibi kullanmamak gerekir. Event idempotency kimliğinin parçası olabilir. Log retention politikasıyla birlikte saklanabilir.

Timestamp

Upload zamanı incident timeline oluşturur. Server-side UTC timestamp kullanmak sistemler arası karşılaştırmayı kolaylaştırır. UI yerel timezone'a dönüştürebilir. Client clock güvenilir source olarak kullanılmamalıdır. Event created ve processed timestamp ayrı tutulabilir.

Action

Put, delete, copy veya lifecycle delete gibi action türleri ayrılmalıdır. Bu bilgi beklenmeyen silme olayını hızlı tespit eder. User-initiated ve system action ayrımı audit açısından faydalıdır. Action enum merkezi tanımlanmalıdır. Serbest metin category analizi zorlaştırır.

Account/Bucket

Çoklu bucket sisteminde hangi resource üzerinde işlem olduğu logda bulunmalıdır. Environment ve bucket kimliği incident scope belirler. Production ile staging olayları kolay ayrılır. Account identifier hassas güvenlik bilgisi değilse operasyon logunda tutulabilir. Gereksiz tam credential bilgisi asla loglanmamalıdır.

Ayrı Log Bucket

Uzun süreli audit loglarını ayrı bucket'ta saklamak retention yönetimini kolaylaştırabilir. Bu bucket'a runtime uygulamanın delete erişimi verilmemesi düşünülebilir. Lifecycle yasal gereksinime göre ayarlanır. Log bucket erişimi daha dar role ile sınırlandırılabilir. Uygulama logu ile user-upload bucket'ı birbirinden bağımsız yönetilebilir.

Object Lifecycle Management Nedir?

Lifecycle management object'lerin yaşına veya prefix'ine göre otomatik storage işlemleri uygular. Temporary dosyalar silinebilir, eski veriler farklı storage class'a geçirilebilir ve incomplete multipart upload'lar temizlenebilir. Bu yaklaşım manuel cron kodunun önemli bölümünü azaltır. Yanlış rule büyük veri kaybına neden olabileceği için review ve staging test gerekir. Lifecycle-as-code bu değişiklikleri görünür hale getirmek için güçlü bir pratiktir.

Retention Period

Retention verinin ne kadar süre saklanacağını belirler. İş gereksinimi, mevzuat ve maliyet birlikte değerlendirilmelidir. Her veri türü aynı retention süresine sahip olmamalıdır. Temporary export birkaç gün içinde silinebilirken backup aylarca tutulabilir. Policy object prefix ile eşleştirilebilir.

Automatic Expiration

Expiration belirli yaştan sonra object'i otomatik siler. Manual cleanup script ihtiyacını azaltır. Production rule uygulanmadan önce prefix doğrulanmalıdır. Yanlış geniş prefix geri döndürülemez veri kaybı oluşturabilir. Kritik veri bucket lock ile ayrıca korunabilir.

Storage Class Transition

Sık erişilmeyen eski object'ler farklı storage class'a geçirilebilir. Amaç storage maliyetini düşürmektir. Retrieval cost ve minimum storage duration gibi etkiler hesaba katılmalıdır. Her veri tipi transition için uygun değildir. Access pattern metric'leri karar vermeye yardımcı olur.

Multipart Cleanup

Yarım kalan multipart session'lar görünmez storage tüketebilir. Lifecycle bu session'ları belirli süre sonra temizleyebilir. Resume deneyimi için süre çok kısa tutulmamalıdır. Upload session database TTL değeriyle uyumlu olmalıdır. Cleanup sonucu storage büyüme trendinde görülebilir.

Prefix-Based Rules

Lifecycle rule yalnızca belirli prefix'e uygulanabilir. tmp/ kısa retention alırken backups/ uzun süre saklanabilir. Bu özellik bucket sayısını gereksiz artırmadan farklı policy uygulamayı sağlar. Naming convention bozulursa rule yanlış object'lere uygulanabilir. Prefix değişikliği migration planıyla yapılmalıdır.

Lifecycle ile Dosyaları Otomatik Silme

Temporary object'leri manuel script ile takip etmek yerine lifecycle kullanmak daha güvenilir olabilir. Export dosyaları, cache nesneleri ve eski loglar belirli süre sonra otomatik silinebilir. Retention süresi business owner tarafından onaylanmalıdır. Kullanıcı dosyaları için otomatik silme ürün davranışıyla uyumlu olmalıdır. Database metadata'nın lifecycle deletion ile senkronize edilmesi unutulmamalıdır.

Temporary Uploads

Upload başlamış fakat tamamlanmamış veya doğrulanmamış dosyalar temporary prefix'te tutulabilir. Belirli süre içinde processing tamamlanmazsa otomatik silinebilir. Bu alan public erişime açık olmamalıdır. Database stale upload kayıtları da scheduled job ile temizlenebilir. Lifecycle iki sistemi tamamen senkron tutmaz, reconciliation gerekebilir.

Export Files

Kullanıcı için oluşturulan rapor veya export dosyaları çoğu zaman kalıcı saklanmak zorunda değildir. Birkaç gün sonra otomatik silmek storage kullanımını azaltır. UI kullanıcıya indirme linkinin ne zaman biteceğini gösterebilir. Expiration zamanı database üzerinde de tutulabilir. Silinen object için eski link güvenli hata döndürmelidir.

Logs

Log retention güvenlik ve mevzuat gereksinimine göre seçilmelidir. Çok uzun retention maliyeti artırabilir. Çok kısa retention incident analizini zorlaştırır. Yaşa göre storage class transition kullanılabilir. Lifecycle deletion audit policy ile uyumlu olmalıdır.

Cache Objects

Cache amaçlı derivative object'ler gerektiğinde yeniden üretilebilir. Bu nedenle daha kısa retention uygulanabilir. Orijinal object silinmediyse cache miss sonrası yeniden processing yapılabilir. Cache object key deterministic oluşturulabilir. Kullanım çok yüksekse sık deletion ek processing maliyeti yaratabilir.

7/30/90 Günlük Retention

7, 30 veya 90 gün gibi süreler operasyonlarda sık kullanılan örneklerdir. Ancak sırf yaygın oldukları için seçilmemelidir. Veri değerinin zaman içinde nasıl değiştiği düşünülmelidir. Compliance daha uzun saklama gerektirebilir. Storage cost modeli retention kararını destekleyebilir.

İş Gereksinimine Göre Süre

Retention teknik ekip tarafından tek başına belirlenmemelidir. Product, legal ve security beklentileri farklı olabilir. Kullanıcı silme talebi lifecycle süresinden bağımsız daha hızlı hard delete gerektirebilir. Backup retention ise recovery objective'e bağlıdır. Policy dokümante edilip otomasyona dönüştürülmelidir.

Lifecycle Rule Nasıl Tasarlanır?

Lifecycle rule açık bir rule id, prefix ve action tanımına sahip olmalıdır. Expiration ile storage transition aynı veri üzerinde birlikte kullanılabilir. Birden fazla kuralın aynı object'i nasıl etkilediği değerlendirilmelidir. Production rule değişiklikleri code review ve staging test sürecinden geçmelidir. Özellikle delete action için dry-run benzeri inventory analizi yapılması veri kaybı riskini azaltır.

Rule ID

Rule id kuralın amacını anlaşılır biçimde ifade etmelidir. temp-uploads-expire-7d gibi isimler operasyon sırasında faydalıdır. Sadece rule1 gibi anlamsız isimlerden kaçınılmalıdır. ID version kontrolünde takip edilir. Incident sırasında hangi policy'nin object'i sildiği daha kolay bulunur.

Prefix

Prefix kuralın hangi object grubuna uygulanacağını belirler. Yanlış prefix kritik veriyi kapsayabilir. Production öncesinde mevcut object listesiyle rule kapsamı kontrol edilmelidir. Prefix naming convention değişirse lifecycle config de güncellenmelidir. Çok genel boş prefix bütün bucket'ı etkileyebilir.

Age

Age object'in belirli yaştan sonra hangi action'a gireceğini tanımlar. Creation veya modification davranışı platform özelliğine göre anlaşılmalıdır. Business retention ile teknik age hesabı aynı anlama gelmelidir. Saat dilimi UI'da kafa karıştırmamalıdır. Policy dokümanı gün bazında açık süre belirtmelidir.

Storage Transition

Object belirli yaştan sonra Infrequent Access gibi sınıfa geçirilebilir. Transition öncesinde access pattern analiz edilmelidir. Çok sık okunan veri retrieval maliyetini artırabilir. Minimum storage duration etkisi hesaba katılmalıdır. Transition yalnızca depolama fiyatına bakılarak seçilmemelidir.

Expiration

Expiration irreversible delete davranışı oluşturabilir. Kritik veri için backup veya lock gereksinimi değerlendirilmelidir. Kural uygulanmadan önce sample object listesi gözden geçirilebilir. Database metadata'nın orphan durumuna düşmemesi gerekir. Delete event reconciliation için kullanılabilir.

Birbiriyle Çakışan Kurallar

Aynı object birden fazla lifecycle rule ile eşleşebilir. Hangi action'ın ne zaman uygulanacağı anlaşılmalıdır. Çakışan retention politikaları beklenmeyen silmeye yol açabilir. Configuration testleri örnek key'ler üzerinde beklenen rule mapping'ini doğrulayabilir. Tekrarlayan kurallar sadeleştirilmelidir.

R2 Storage Class Nedir?

Storage class verinin erişim sıklığı ve maliyet yapısına göre farklı depolama seçenekleri sunar. Standard sık erişilen veriler için doğal seçimdir. Infrequent Access daha seyrek okunan veri için değerlendirilebilir. Sadece aylık storage fiyatına bakmak yanlış karar verebilir. Retrieval ve minimum storage duration gibi maliyetler toplam sahip olma hesabına dahil edilmelidir.

Standard

Standard class sık erişilen object'ler için uygundur. Kullanıcı medyası ve aktif uygulama dosyaları bu gruba girebilir. Retrieval pattern tahmin edilemiyorsa güvenli başlangıç olabilir. Daha sonra metrics üzerinden eski object'ler farklı class'a taşınabilir. Lifecycle transition otomasyonu bu süreci kolaylaştırır.

Infrequent Access

Infrequent Access nadiren okunan arşiv verileri için değerlendirilebilir. Backup ve eski loglar örnek kullanım alanıdır. Retrieval maliyeti ve minimum saklama şartı hesaba katılmalıdır. Sık okunan object'i IA'ya taşımak toplam maliyeti artırabilir. Access frequency gerçek metric ile doğrulanmalıdır.

Storage Cost

Storage cost GB-month bazında değerlendirilebilir. Ancak object sayısı ve operation maliyeti toplam faturayı etkiler. IA kullanıldığında retrieval ek maliyet oluşturabilir. Lifecycle doğru veri segmentini seçmelidir. Cost dashboard veri türüne göre ayrıştırılabiliyorsa optimizasyon daha kolay olur.

Retrieval Cost

Seyrek erişim sınıfından veri okuma ek maliyet oluşturabilir. Sık indirilen kullanıcı medyasında bu ciddi fark yaratabilir. Cache bazı read isteklerini origin'e ulaşmadan karşılayabilir. Retrieval frequency ölçülmeden IA'ya geçiş yapılmamalıdır. Restore edilen backup sayısı bile maliyet tahminine dahil edilmelidir.

Minimum Storage Duration

Bazı storage class seçeneklerinde minimum saklama süresi maliyet modelinin parçası olabilir. Çok kısa ömürlü temporary object'i bu sınıfa geçirmek avantaj sağlamayabilir. Lifecycle transition zamanı bu koşulu dikkate almalıdır. Kullanıcı upload'larının hızlı silinebildiği ürünlerde dikkatli olunmalıdır. Total cost hesabı gerçek object yaşam süresini kullanmalıdır.

Standard mı Infrequent Access mı?

Doğru class erişim sıklığına göre seçilmelidir. Sık kullanılan dosyada Standard genellikle daha öngörülebilir olur. Arşiv backup ve eski loglarda IA anlamlı olabilir. Kullanıcı medyası yaşlandıkça erişim azalıyor olabilir ve lifecycle transition uygulanabilir. Karar storage fiyatı, read sayısı ve retention süresinin birlikte hesaplanmasıyla verilmelidir.

Sık Okunan Dosyalar

Profil görselleri veya aktif ürün medyası sık read alabilir. Bu veriyi IA'ya taşımak retrieval maliyeti oluşturabilir. CDN cache hit yüksekse origin read sayısı düşebilir. Yine de cache miss pattern'i hesaba katılmalıdır. Standard başlangıç seçimi genellikle daha basittir.

Nadiren Okunan Dosyalar

Aylarca hiç erişilmeyen arşiv verileri IA için adaydır. Eski audit export veya cold backup buna örnek olabilir. Lifecycle ile belirli yaştan sonra transition uygulanabilir. Gerektiğinde restore maliyeti bütçeye dahil edilmelidir. Access pattern zaman içinde tekrar ölçülmelidir.

Backup

Backup çoğunlukla yalnızca incident veya restore testinde okunur. Bu nedenle IA ekonomik olabilir. Ancak sık restore testi yapılan geliştirme backup'ları farklı profile sahiptir. Minimum saklama süresi retention politikasıyla uyumlu olmalıdır. Kritik recovery ihtiyacında retrieval performansı da değerlendirilmelidir.

Log Archive

Eski loglar normal operasyon sırasında nadiren okunabilir. Incident durumunda geniş tarih aralığı taranabilir. IA kullanımı normal ayda düşük maliyet sağlarken incident ayında retrieval artışı yaratabilir. Bu trade-off kabul edilebilir olabilir. Log analytics sistemi doğrudan sık object read yapıyorsa Standard daha uygun olabilir.

Kullanıcı Medyası

Yeni kullanıcı medyası genellikle daha sık erişilir. Yaşlandıkça erişim oranı düşebilir. Lifecycle belirli süreden sonra class transition yapabilir. Ancak viral veya evergreen içerik eski olsa da yoğun read alabilir. Access-based dinamik analiz statik age kuralından daha doğru olabilir.

Retrieval Pattern Analizi

Object access log veya uygulama metric'leri okunma sıklığını gösterebilir. Prefix bazlı analiz hangi veri türünün cold olduğunu ortaya çıkarır. Sadece toplam bucket read sayısı yeterli değildir. Yaş grubu ve file type kırılımı faydalıdır. Lifecycle policy gerçek pattern'e göre periyodik güncellenebilir.

Lifecycle ile Infrequent Access'a Geçiş

Lifecycle object yaşına göre otomatik storage class geçişi sağlayabilir. Yeni veriler ilk dönemde Standard tutulabilir. Belirli süre sonra erişimin azalacağı biliniyorsa IA'ya taşınabilir. Prefix bazlı rule farklı veri türlerinin ayrı yaş politikası kullanmasını sağlar. Retrieval cost transition kararının mutlaka bir parçası olmalıdır.

Standard'da İlk Dönem

Yeni content ilk haftalarda veya aylarda sık kullanılabilir. Standard class bu yoğun read döneminde daha uygun olabilir. Metric gerçekten kullanımın zamanla düştüğünü doğrulamalıdır. Tek tip lifecycle bütün veri türlerine uygulanmamalıdır. Backup dosyaları başlangıçtan itibaren farklı politika kullanabilir.

Belirli Gün Sonrası IA

Object yaşı belirli eşiği geçince otomatik transition yapılabilir. Süre iş verisine göre seçilir. 30 gün her sistem için doğru değildir. Minimum storage duration ve retrieval beklentisi hesaba katılmalıdır. Policy değişikliği cost raporuyla doğrulanmalıdır.

Prefix Bazlı Transition

logs/archive/ için transition uygulanırken users/avatars/ Standard kalabilir. Prefix farklı access pattern'leri aynı bucket içinde ayırır. Naming convention burada kritik rol oynar. Object yanlış prefix'e yazılırsa yanlış class'a geçebilir. Upload helper key standardını enforce etmelidir.

Retrieval Cost'u Hesaba Katmak

IA storage fiyatı düşük olabilir fakat read işlemi ek maliyet yaratabilir. Bir object sık kullanılıyorsa toplam fatura Standard'dan daha yüksek olabilir. Cache hit ratio bu hesabı etkiler. Retrieval sayısı tahmin değil metric üzerinden alınmalıdır. Cost optimization periyodik olarak yeniden yapılmalıdır.

""En Ucuz Storage Class"" Her Zaman Daha Ucuz mudur?

En düşük GB-month fiyatı her zaman en düşük toplam maliyet anlamına gelmez. Retrieval, operation ve minimum storage duration maliyetleri sonucu değiştirebilir. Sık okunan veri daha pahalı storage class'ta bile toplamda ucuz olabilir. Bu nedenle total cost of ownership hesaplanmalıdır. Özellikle milyonlarca küçük object bulunan sistemlerde request sayısı depolama fiyatından daha önemli hale gelebilir.

Storage Fiyatı

Storage fiyatı object'in ne kadar süre ve ne kadar veri tuttuğuyla ilgilidir. Büyük arşivlerde önemli bir kalemdir. Ancak tek maliyet değildir. Read ve write operation'ları ayrıca ücretlendirme modeli içinde değerlendirilebilir. Cost dashboard bütün kalemleri birlikte göstermelidir.

Read Sıklığı

Object günde yüzlerce kez okunuyorsa retrieval modelinin etkisi büyür. Eski object her zaman cold değildir. Kullanıcı davranışı yaşa göre analiz edilmelidir. Cache origin read sayısını azaltabilir. Access frequency storage class kararının temel sinyalidir.

Retrieval Fee

IA sınıfındaki read işlemleri ek retrieval maliyeti oluşturabilir. Normal günlerde düşük read varsa bu kabul edilebilir. Incident veya toplu analytics işlemi sırasında maliyet aniden artabilir. Kullanım senaryoları dönemsel peak davranışını içermelidir. Sadece ortalama ay üzerinden karar verilmemelidir.

Operation Cost

Put, get ve list gibi operasyonlar request sayısıyla maliyet yaratabilir. Milyonlarca tiny object bu yüzden beklenenden pahalı olabilir. Birleştirilmiş archive formatı bazı batch verilerinde avantaj sağlar. Bununla birlikte random access ihtiyacını azaltabilir. Operation cost storage design kararının bir parçasıdır.

Minimum Storage Duration

Kısa ömürlü dosya erken silinse bile minimum süre maliyet etkisi oluşturabilir. Temporary export veya cache object'lerinde bu önemlidir. IA kullanımı bu nedenle her kısa dosyada avantaj sağlamaz. Lifecycle transition object'in beklenen yaşam süresine göre ayarlanmalıdır. Cost model gerçek retention pattern ile hesaplanmalıdır.

Total Cost of Ownership

Toplam maliyet storage, operation, retrieval ve compute giderlerinin birleşimidir. Upload processing ve cache altyapısı da bu hesaba dahil edilebilir. Developer operasyon süresi bile büyük sistemlerde önemli olabilir. En ucuz görünen teknik çözüm bakım yükü nedeniyle daha pahalı hale gelebilir. Optimizasyon tek fiyat kalemine odaklanmamalıdır.

Bucket Lock Nedir?

Bucket Lock belirli object'lerin silinmesini veya overwrite edilmesini önleyen retention kontrolüdür. Backup, audit veya compliance verilerinde önemli olabilir. Time-based veya belirli tarihe kadar retention uygulanabilir. Indefinite lock çok güçlü bir kontrol olduğu için dikkatli kullanılmalıdır. Lifecycle delete rule locked object'i silme beklentisine sahip olsa bile lock politikası öncelikli olabilir.

Object Silinmesini Engellemek

Locked object normal delete çağrısıyla kaldırılamayabilir. Bu özellik yanlışlıkla veya kötü niyetli silme riskini azaltır. Backup ransomware senaryolarında ek koruma sağlayabilir. Lock süresi business recovery politikasına göre belirlenmelidir. Gereksiz uzun lock storage maliyetini kalıcı hale getirebilir.

Object Overwrite'ını Engellemek

Immutable artifact veya audit log üzerinde overwrite engeli önemli olabilir. Aynı key ile yeni content yazmak mümkün olmamalıdır. Uygulama versioned veya unique key kullanmalıdır. Release artifact'ları bu modelden faydalanabilir. Lock davranışı deployment pipeline'ında önceden test edilmelidir.

Time-Based Retention

Object oluşturulduktan sonra belirli süre değiştirilemez veya silinemez. Backup için örneğin belirli recovery penceresi korunabilir. Süre dolunca normal lifecycle devreye girebilir. Policy legal gereksinime göre belirlenmelidir. Çok kısa veya çok uzun retention farklı riskler taşır.

Date-Based Retention

Belirli tarihe kadar object üzerinde lock tutulabilir. Regulatory deadline gibi durumlarda kullanışlı olabilir. Tarih timezone ve uygulama formatı açısından açık belirtilmelidir. Lock date yanlış girilirse geri dönüş zor olabilir. Production değişiklikleri çift review sürecinden geçebilir.

Indefinite Lock

Indefinite lock silme işlemini süresiz engelleyebilir. Çok özel compliance ihtiyaçları dışında dikkatli kullanılmalıdır. Yanlış object üzerinde uygulandığında storage kalıcı hale gelebilir. Operational break-glass süreçleri varsa önceden belgelenmelidir. Maliyet etkisi approval sürecinde açıkça gösterilmelidir.

Bucket Lock ile Lifecycle Arasındaki Fark

Lifecycle ve Bucket Lock birbirinin zıttı sayılabilecek farklı amaçlara sahiptir. Lifecycle object'i belirli zamanda otomatik silmek veya taşımak için kullanılır. Lock ise object'in silinmesini engeller. Aynı object iki politikaya tabi olduğunda lock beklentisi daha güçlü koruma sağlar. Bu etkileşim yanlış tasarlanırsa beklenen cleanup gerçekleşmez ve storage maliyeti artabilir.

Lifecycle Otomatik Silme Yapar

Lifecycle expiration belirli yaştaki object'i otomatik temizler. Temporary data ve log retention için faydalıdır. İnsan müdahalesine ihtiyaç duymaz. Yanlış prefix büyük veri kaybına yol açabilir. Delete policy production review sürecine dahil edilmelidir.

Bucket Lock Silinmeyi Engeller

Lock retention penceresi boyunca delete işlemini reddeder. Bu özellik backup ve compliance verisini korur. Uygulama yanlışlıkla delete çağrısı gönderse bile object korunabilir. Lock süresi dolmadan lifecycle cleanup beklenmemelidir. Monitoring beklenen silinmeyen object'leri maliyet açısından gösterebilir.

Lock'ın Önceliği

Koruyucu lock politikası lifecycle silme isteğinin önünde değerlendirilir. Bu nedenle lifecycle rule tanımlamak locked object'in retention süresini kısaltmaz. Mimari ekip iki politikayı birlikte modellemelidir. Maliyet tahmini lock süresini temel almalıdır. Test bucket üzerinde etkileşim davranışı doğrulanabilir.

Compliance ve Retention

Compliance çoğu zaman minimum saklama süresi belirler. Lifecycle maksimum operasyon retention politikası olabilir. Lock minimum güvenli süreyi enforce eder. Süreler çelişmemelidir. Legal değişiklik olduğunda iki config birlikte gözden geçirilmelidir.

Yanlış Konfigürasyon Riski

Lock yanlış object grubuna uygulanırsa dosyalar planlanandan uzun saklanabilir. Lifecycle yanlış prefix kullanırsa kritik data silinmeye çalışılabilir. Configuration-as-code ve review bu riskleri azaltır. Production öncesinde örnek object setiyle policy simulation yapılabilir. Storage governance teknik ve business ekiplerin ortak sorumluluğudur.

R2'de Silme Stratejisi Nasıl Tasarlanmalı?

Silme işlemi yalnızca DeleteObject çağrısı değildir. User-initiated delete, soft delete, delayed hard delete ve lifecycle expiration farklı iş ihtiyaçlarını temsil eder. Database ile object storage state'i birbirinden kopmamalıdır. Locked object silinemeyebilir ve UI bunu doğru göstermelidir. Reconciliation job orphaned record problemlerini düzenli olarak kontrol etmelidir.

User-Initiated Delete

Kullanıcı kendi dosyasını silmek istediğinde önce authorization yapılmalıdır. Database kaydı soft deleted duruma getirilebilir. Object hemen veya belirli gecikme sonrası fiziksel silinebilir. Audit ihtiyacı varsa delete actor bilgisi tutulabilir. Silme tamamlandığında quota hesabı güncellenmelidir.

Soft Delete

Soft delete business record'u görünmez yapar fakat object fiziksel olarak kalır. Yanlış silme durumunda geri alma imkanı sağlar. Storage retention süresi belirlenmelidir. Soft deleted object public erişime devam etmemelidir. Belirli süre sonra hard delete job çalışabilir.

Delayed Hard Delete

Soft delete sonrası 7 veya 30 günlük geri alma penceresi uygulanabilir. Süre dolunca lifecycle veya scheduled worker object'i kalıcı siler. Database purge aynı akışta yapılabilir. Kullanıcı arayüzü geri alma süresini açık gösterebilir. Locked object bu sürenin üzerinde retention uygulayabilir.

Lifecycle Delete

Lifecycle business event olmadan yaş bazlı silme yapar. Temporary object'ler için uygundur. Kullanıcı veri kaydıyla ilişkili object'lerde delete event database'e yansıtılmalıdır. Aksi durumda UI kayıp object linki gösterebilir. Lifecycle scope business owner tarafından onaylanmalıdır.

Locked Object

Locked object normal delete workflow içinde hata döndürebilir. Uygulama bunu unexpected failure olarak değil policy sonucu olarak ele almalıdır. Kullanıcı silme talebi compliance lock ile çelişebilir. UI business ve legal policy'ye uygun mesaj göstermelidir. Retention süresi dolduğunda hard delete tekrar denenebilir.

Database ve Object Storage Senkronizasyonu

Database kaydı object key ve state bilgisini tutar. Object silindiğinde metadata güncellenmelidir. Transaction tek sistem üzerinde olmadığı için eventual consistency kabul edilmelidir. Event ve reconciliation job bu farkı kapatır. İki yönlü orphan kontrolü düzenli çalıştırılmalıdır.

Orphaned Object Problemi

Database ile object storage ayrı sistemler olduğu için zaman zaman orphan oluşabilir. Database kaydı silinmişken object kalabilir veya tam tersi olabilir. Network failure bu durumu kolayca yaratır. Periodic reconciliation her iki sistemi karşılaştırarak farkları bulur. Garbage collection policy veriyi hemen silmeden önce güvenli bekleme süresi uygulayabilir.

Database Kaydı Silinip Dosyanın Kalması

Database transaction başarılı olup object delete başarısız olabilir. Dosya artık kullanıcıya bağlı görünmez ama storage tüketmeye devam eder. Delete retry queue kullanılabilir. Reconciliation object prefix ile database kayıtlarını karşılaştırabilir. Belirli grace period sonrası orphan object silinebilir.

Dosya Silinip Database Kaydının Kalması

Object fiziksel silinip database kaydı aktif kalırsa kullanıcı broken link görür. Delete event database'i expired veya missing duruma çekebilir. Download endpoint object bulunamadığında reconciliation signal üretebilir. UI güvenli fallback göstermelidir. Beklenmeyen missing object incident metric olarak izlenebilir.

Periodic Reconciliation

Scheduled job storage inventory ile database kayıtlarını karşılaştırabilir. Çok büyük bucket'ta bütün object'leri her gün listelemek pahalı olabilir. Prefix veya tarih partition üzerinden incremental tarama yapılabilir. Sonuç hemen silmek yerine review queue'ya yazılabilir. Reconciliation job'ın kendisi idempotent olmalıdır.

Delete Event Notification

Object silindiğinde event database senkronizasyonuna yardımcı olur. Lifecycle deletion ile manual deletion ayrımı faydalıdır. Event duplicate gelebilir. Consumer mevcut database state'i kontrol etmelidir. Event kaybolma ihtimaline karşı reconciliation yine gereklidir.

Garbage Collection Job

Garbage collector doğrulanmış orphan object'leri temizleyebilir. Yanlış pozitif riskine karşı grace period uygulanmalıdır. Kritik object prefix'leri bu job dışında tutulabilir. Delete logu audit için saklanmalıdır. Job silinen byte miktarını cost metric olarak raporlayabilir.

R2'de Public ve Private Bucket

Object storage tasarımında varsayılan olarak private model daha güvenlidir. Public erişim yalnızca gerçekten herkesin görebileceği medya için açılmalıdır. User-generated content bile her zaman public olmak zorunda değildir. Internal data ve hassas belgeler presigned GET veya Worker proxy ile sunulabilir. Access classification bucket oluşturulmadan önce belirlenmelidir.

Private Varsayılan Model

Private bucket beklenmeyen veri ifşasını azaltır. Uygulama yalnızca authorization sonrası object erişimi sağlar. Public domain açmak explicit karar olmalıdır. Internal backup ve kullanıcı belgeleri private tutulmalıdır. Security review bucket exposure durumunu düzenli kontrol etmelidir.

Public Bucket

Public bucket herkesin erişebileceği içerik için kullanılabilir. Marketing asset veya açık kaynak artifact buna örnek olabilir. Yine de upload write erişimi public olmamalıdır. Custom domain ve cache production dağıtımında değerlendirilebilir. Object key içinde gizli bilgi bulunmamalıdır.

User-Generated Content

Kullanıcı içeriğinin public olup olmadığı ürün özelliğine bağlıdır. Private mesaj eki ile public profil resmi aynı policy'yi kullanmamalıdır. Public user content moderation ve malware scanning gerektirir. Object active olmadan cache'e yayılmamalıdır. Delete ve privacy request süreçleri storage üzerinden de uygulanmalıdır.

Internal Data

Şirket içi export, log veya analiz dosyaları public domain üzerinden sunulmamalıdır. Service credential veya Worker authorization kullanılabilir. Access log tutulması faydalıdır. Personel rolü değiştiğinde permission otomatik güncellenmelidir. Shared permanent URL yerine time-limited erişim kullanılabilir.

Hassas Dosyalar

Kimlik belgesi veya sözleşme gibi dosyalar yüksek güvenlik gerektirir. Private bucket temel başlangıçtır. Download endpoint her request'te authorization yapmalıdır. Presigned GET çok kısa süreli olabilir. Logging dosya içeriği veya tam URL taşımamalıdır.

r2.dev ile Custom Domain Arasındaki Fark

Development ve production yayınlama ihtiyaçları aynı değildir. r2.dev benzeri development erişimi hızlı test için kullanılabilir. Production'da custom domain cache ve güvenlik özellikleri açısından daha fazla kontrol sunabilir. WAF veya access policy uygulama ihtiyacı varsa custom domain daha uygundur. Public asset dağıtım modeli deployment öncesinde açıkça seçilmelidir.

Development Kullanımı

Development erişimi hızlı test için faydalıdır. Production trafik için aynı endpoint'i kullanmak gerekli olmayabilir. Domain ve cache davranışı production'dan farklı olabilir. Test linkleri kullanıcıya kalıcı URL olarak verilmemelidir. Environment config endpoint farkını açık biçimde yönetmelidir.

Production Custom Domain

Custom domain kullanıcıya markalı ve kontrollü asset adresi sağlar. Cloudflare cache özellikleri domain üzerinde uygulanabilir. Security rule ve access policy eklenebilir. URL yapısı storage sağlayıcı detayını gizleyebilir. Domain migration ileride storage backend değişimini kolaylaştırır.

Caching

Public object custom domain üzerinden edge cache'e alınabilir. Sık okunan object'ler origin request sayısını azaltır. Cache-Control header'ları içerik türüne göre ayarlanmalıdır. Immutable versioned key uzun TTL için uygundur. Update edilen aynı key cache invalidation gerektirebilir.

WAF

Custom domain önünde web security policy uygulanabilir. Bot veya abuse traffic filtrelenebilir. Public download endpoint'lerinde rate limit eklenebilir. WAF storage authentication yerine geçmez. Private object yine application authorization gerektirir.

Access Control

Custom domain üzerinden erişim business policy ile sınırlandırılabilir. Public ve private path'ler ayrı domain kullanabilir. Worker proxy authentication kontrolünü uygulayabilir. Cache private response için dikkatli yapılandırılmalıdır. Yanlış cache key kullanıcılar arası veri sızıntısı oluşturabilir.

Bot Management

Public asset endpoint yoğun bot trafiği alabilir. Bot management gereksiz origin veya cache miss yükünü azaltabilir. Image scraping business ihtiyacına göre kontrol edilebilir. False positive kullanıcı erişimini engellememelidir. Metric gerçek bot ve normal trafik dağılımını göstermelidir.

Private Dosyalar Nasıl İndirilir?

Private object doğrudan public URL ile sunulmamalıdır. Kullanıcı önce backend'e gelir ve authorization kontrolünden geçer. Backend Worker proxy ile dosyayı stream edebilir veya kısa ömürlü presigned GET URL üretebilir. İki yöntemin bandwidth ve kontrol seviyesi farklıdır. Hassas dosyada access log ve kısa süreli yetki kullanmak faydalıdır.

Worker Proxy

Worker request'i doğrular ve object'i R2 binding üzerinden okur. Response doğrudan kullanıcıya stream edilebilir. Backend her request üzerinde authorization kontrolü yapar. Büyük dosyada Worker üzerinden veri geçişinin performans etkisi ölçülmelidir. Range request desteği medya kullanımında ayrıca değerlendirilmelidir.

Presigned GET URL

Backend authorization sonrası kısa süreli GET URL üretebilir. Client dosyayı doğrudan storage'dan indirir. Backend bandwidth tüketimi azalır. URL paylaşılırsa expiration süresi içinde başka kişi tarafından kullanılabilir. Çok hassas içerikte kısa expiration ve tek kullanımlık application token modeli değerlendirilebilir.

Authentication

Download endpoint kullanıcı kimliğini doğrulamalıdır. Public olmayan dosya anonymous request'e açılmamalıdır. Authentication session süresi dosya erişim politikasına uygun olmalıdır. Download audit log kullanıcı kimliğiyle ilişkilendirilebilir. Hassas veride step-up authentication gerekebilir.

Authorization

Kullanıcı dosyanın sahibi veya yetkili rol olmalıdır. Object key client tarafından verilse bile backend database ownership kontrolü yapmalıdır. Tahmin edilebilir key authorization yerine geçmez. Tenant sınırı ayrıca doğrulanmalıdır. Horizontal privilege escalation testleri indirme endpoint'ini kapsamalıdır.

Time-Limited Access

Private dosya URL'si kalıcı olmamalıdır. Presigned URL kısa süreli erişim sağlar. Kullanıcı uzun video indiriyorsa sürenin download başlamasına yeterli olması gerekir. Çok uzun expiration gereksiz risk yaratır. Paylaşım özelliği varsa ayrı share token ve revoke mekanizması tasarlanabilir.

R2 Custom Domain ve Cache

Custom domain yalnızca estetik URL sağlamaz. Edge cache, security policy ve browser cache kontrolü için de merkezi katman oluşturur. Immutable object key kullanıldığında uzun TTL güvenle uygulanabilir. Aynı key üzerine overwrite yapılıyorsa purge ihtiyacı oluşur. Cache stratejisi object lifecycle ve update modeliyle birlikte tasarlanmalıdır.

Custom Domain

Özel domain storage endpoint detayını kullanıcıdan gizler. CDN ve security policy uygulamasını kolaylaştırır. Birden fazla bucket farklı subdomain kullanabilir. DNS ve TLS platform tarafından yönetilebilir. Domain yapısı public ve private content ayrımını yansıtabilir.

Cloudflare Cache

Edge cache sık erişilen object'i kullanıcıya yakın noktada tutabilir. R2 read request sayısı azalabilir. Cache key query string ve header davranışına göre dikkatli ayarlanmalıdır. Private içerik shared cache'e alınmamalıdır. Cache hit ratio önemli performance ve cost metriğidir.

Cache-Control

Cache-Control object'in browser ve CDN tarafından ne kadar süre saklanacağını belirler. Versioned immutable key için uzun max-age kullanılabilir. Sık değişen aynı key için kısa TTL daha güvenlidir. Private response uygun cache directive kullanmalıdır. Header politikası file type bazında tanımlanabilir.

Browser Cache

Browser cache aynı kullanıcının tekrar indirmesini azaltır. Büyük görsel ve static asset için faydalıdır. Kullanıcının hemen güncel dosyayı görmesi gerekiyorsa versioned URL tercih edilir. Cache busting query param yerine immutable object key daha temiz olabilir. Browser cache private sensitive data için dikkatli yapılandırılmalıdır.

CDN Cache

CDN cache bir object'i birçok kullanıcı için ortak edge noktasında saklar. Public content için origin load'u ciddi biçimde azaltabilir. Hit ratio yükseldikçe R2 read operation sayısı düşebilir. Çok düşük TTL bu faydayı sınırlar. Personalized veya authorization bağımlı response shared cache'ten ayrılmalıdır.

Cache Purge

Aynı key altında content değişiyorsa eski cache entry temizlenmelidir. Purge API otomasyon içinde kullanılabilir. Sık purge cache verimliliğini düşürür. Immutable key versioning purge ihtiyacını büyük ölçüde azaltır. Database yeni key'e işaret ederek güncel içeriği sunabilir.

Cache Kullanımı R2 Maliyetlerini Nasıl Etkiler?

Cache yalnızca latency değil object read sayısını da etkiler. Sık erişilen public dosya edge'de karşılanırsa origin'e daha az request gider. Bu durum Class B operasyon maliyetini azaltabilir. Cache hit ratio bu kazancın ana ölçümüdür. Çok kısa TTL veya sürekli purge kullanımı cache avantajını azaltır.

Daha Az Origin Read

Cache hit olduğunda R2'den yeni object read gerekmeyebilir. Özellikle viral image veya static asset'te büyük fark oluşur. Edge cache kullanıcıya daha hızlı response verir. Object update sıklığı düşükse uzun TTL kullanılabilir. Origin read metric cache stratejisinin etkisini gösterir.

Class B Operation

Read benzeri operasyonlar maliyet modelinde ayrı sınıfta değerlendirilebilir. Sık GetObject request sayısı toplam faturayı etkileyebilir. Cache bu sayıyı azaltabilir. HEAD request'lerinin gereksiz tekrarı da gözden geçirilmelidir. Application access pattern operation metric'leriyle izlenmelidir.

Cache Hit Ratio

Hit ratio toplam request içinde cache'ten cevaplanan oranı gösterir. Public static content'te yüksek değer hedeflenebilir. Düşük hit ratio query key veya TTL problemine işaret edebilir. Coğrafi trafik dağılımı da sonucu etkiler. Cost analizinde hit ratio R2 read sayısıyla birlikte değerlendirilmelidir.

TTL

Uzun TTL hit oranını artırabilir. İçerik sık değişiyorsa stale response riski oluşur. Immutable key bu ikilemi büyük ölçüde çözer. Temporary veya personalized içerikte farklı TTL kullanılmalıdır. Cache policy object türüne göre ayrıştırılmalıdır.

Frequently Accessed Objects

Sık erişilen object'ler cache optimizasyonunun en büyük kazanç alanıdır. Access log üzerinden hot key listesi çıkarılabilir. Çok büyük hot object edge cache kapasitesi ve range request davranışı açısından incelenebilir. Public media buna yaygın örnektir. Hot object analizi storage class kararını da etkiler.

R2 Maliyet Modeli Nasıl Çalışır?

R2 maliyetini yalnızca depolanan GB üzerinden hesaplamak eksik sonuç verir. Storage, Class A operasyonları, Class B operasyonları ve bazı storage class retrieval davranışları birlikte değerlendirilmelidir. Egress avantajı önemli olsa da diğer maliyet kalemleri devam eder. Free tier küçük projelerde faydalı olabilir. Production bütçesi gerçek request ve object pattern'i üzerinden hesaplanmalıdır.

GB-Month Storage

Depolanan veri miktarı zamanla aylık maliyet üretir. Büyük backup arşivi storage maliyetinde belirgin olur. Lifecycle eski ve gereksiz veriyi otomatik silerek büyümeyi kontrol eder. Compression log ve backup dosyalarında fayda sağlayabilir. Object sayısı ayrıca operasyon maliyetini etkileyebilir.

Class A Operations

Write ve yönetim ağırlıklı object operasyonları farklı maliyet sınıfına girebilir. Yoğun upload sistemi bu request sayısını izlemelidir. Multipart upload tek dosya için birden fazla operation üretir. Çok küçük part size maliyeti artırabilir. Operation metric dosya boyutuyla birlikte analiz edilmelidir.

Class B Operations

Read ve metadata ağırlıklı bazı işlemler Class B içinde değerlendirilebilir. Public asset trafiğinde request sayısı çok yüksek olabilir. CDN cache bu origin request'leri azaltabilir. Uygulamanın gereksiz HEAD kontrolü yapması maliyet oluşturabilir. Read pattern performans kadar cost açısından da optimize edilmelidir.

Data Retrieval

Storage class seçimine bağlı olarak retrieval maliyeti oluşabilir. Standard ve IA davranışı bu açıdan farklı değerlendirilmelidir. Cold backup normalde okunmadığı için uygun olabilir. Kullanıcı medyası sık retrieval yapıyorsa toplam maliyet artabilir. Retrieval metric lifecycle kararını desteklemelidir.

Egress

R2'nin internet veri çıkışı yaklaşımı önemli maliyet avantajı sunabilir. Ancak bunun bütün storage kullanımını ücretsiz yaptığı düşünülmemelidir. Storage ve operation ücretleri devam eder. IA gibi sınıflarda retrieval davranışı ayrıca hesaba katılmalıdır. Toplam maliyet bütün bileşenlerle hesaplanmalıdır.

Free Tier

Küçük proje ve geliştirme ortamı belirli ücretsiz kullanım kotasından faydalanabilir. Production maliyet tahminini sadece free tier'a göre yapmak doğru değildir. Trafik büyüdüğünde gerçek unit cost hesaplanmalıdır. Monitoring mevcut kullanımın free limitlere ne kadar yaklaştığını gösterebilir. Startup aşamasında maliyet sürprizini önlemek için erken budget alarmı kurulmalıdır.

Class A ve Class B Operation Nedir?

Object storage fiyatlandırması yalnızca byte değil request tipini de dikkate alabilir. Upload, copy ve multipart işlemleri ile read ve list işlemleri farklı operation sınıflarına ayrılabilir. Çok küçük object bulunan sistemlerde request sayısı storage miktarından daha büyük maliyet kalemi haline gelebilir. Bu nedenle application metric'lerinde operation count tutulmalıdır. Cost optimization request pattern'i değiştirebilir.

PutObject

PutObject yeni object yazma operasyonudur. Kullanıcı upload sayısı arttıkça request count yükselir. Büyük dosyada multipart farklı sayıda operation üretir. Aynı dosyayı gereksiz overwrite etmek maliyet ve processing yükü yaratabilir. Idempotency duplicate write sayısını azaltır.

CopyObject

CopyObject quarantine'den verified prefix'e geçiş gibi workflow'larda kullanılabilir. Her copy ek operation anlamına gelir. Çok büyük object'lerde copy maliyeti ve süre ölçülmelidir. Mümkünse upload baştan doğru final key'e yapılıp metadata state ile güvenlik yönetilebilir. Ancak security isolation gerektiğinde copy modeli daha anlaşılır olabilir.

Multipart Operations

Create, part upload ve complete adımları tek dosya için birden fazla request üretir. Part size çok küçük olursa operation sayısı hızla yükselir. Bunun karşılığında retry ve resume avantajı elde edilir. Cost ve reliability arasında denge kurulmalıdır. Büyük dosyalarda multipart genellikle bu ek operation'a değer.

GetObject

GetObject object içeriğini okur. Public media sisteminde en sık operasyonlardan biri olabilir. CDN cache hit bu sayıyı azaltabilir. Private download'da authorization öncesinde gereksiz storage read yapılmamalıdır. Range request kullanımının operation ve bandwidth davranışı ayrıca izlenmelidir.

HeadObject

HeadObject içerik indirmeden object metadata kontrolü sağlar. Upload completion ve existence check için kullanışlıdır. Her frontend render'da HEAD göndermek gereksiz request sayısı oluşturabilir. Database object state zaten güvenilir kaynak olabilir. HEAD yalnızca gerçekten doğrulama gerektiğinde kullanılmalıdır.

ListObjects

List operation bucket içindeki key'leri prefix üzerinden taramak için kullanılır. Büyük bucket'ta pagination zorunludur. Kullanıcı UI'sı için her request'te R2 list kullanmak iyi arama deneyimi sağlamaz. Metadata database üzerinden sorgulanabilir. List operation inventory ve background job'larda daha uygun olabilir.

Maliyeti Request Sayısıyla Birlikte Ölçmek

Object storage cost dashboard upload ve read count ile birlikte okunmalıdır. Bir milyon küçük dosya az GB tutsa bile çok sayıda operation üretir. Request per user veya per tenant metriği bütçe planlamasına yardımcı olur. Caching ve aggregation stratejileri request sayısını azaltabilir. Optimizasyon sonrası kullanıcı deneyiminin bozulmadığı doğrulanmalıdır.

R2'de Egress Ücretsiz Olması Ne Anlama Gelir?

Egress yaklaşımı internet veri transferi maliyetinin azaltılması açısından önemli avantajdır. Ancak storage kullanımı, request operasyonları ve belirli retrieval maliyetleri devam eder. Bu nedenle zero egress ifadesini zero storage cost olarak yorumlamak yanlıştır. Yüksek trafik sisteminde egress avantajı toplam bütçeyi ciddi biçimde etkileyebilir. Yine de doğru lifecycle ve caching maliyet optimizasyonunun önemli parçalarıdır.

Internet'e Data Transfer

Kullanıcıların object'i internet üzerinden indirmesi yüksek trafik oluşturabilir. R2'nin egress modeli bu trafik için avantaj sağlayabilir. Özellikle medya ve software artifact dağıtımında fark önemli olabilir. CDN cache latency'yi ayrıca iyileştirir. Trafik pattern'i object read operation maliyetinden ayrı değerlendirilmelidir.

Storage Cost'un Devam Etmesi

Dosyanın internet transferi avantajlı olsa da storage alanı ücretsiz değildir. Büyük arşiv aylarca saklandığında GB-month maliyeti oluşur. Lifecycle gereksiz veriyi temizlemelidir. Compression özellikle backup ve loglarda depolanan byte miktarını azaltır. Cost raporu veri türü bazında hazırlanabilir.

Request Cost'un Devam Etmesi

Her upload veya read belirli operation maliyeti üretebilir. Milyonlarca küçük request toplam faturayı etkileyebilir. Egress avantajı request ücretini ortadan kaldırmaz. Cache ve batching bazı operation sayılarını azaltabilir. Application design cost modelini doğrudan etkiler.

Infrequent Access Retrieval

IA sınıfında veri okuma ek retrieval maliyeti oluşturabilir. Bu kalem internet egress politikasından farklıdır. Cold object için düşük read oranı avantaj sağlayabilir. Sık okunan object'te ise toplam maliyet artabilir. Storage class seçimi access metric'ine dayanmalıdır.

""Zero Egress = Zero Cost"" Yanılgısı

Veri transferi tek maliyet kalemi değildir. Storage, operation, processing ve gerektiğinde retrieval maliyeti devam eder. Direct upload backend bandwidth maliyetini azaltabilir. Lifecycle storage büyümesini kontrol eder. Total cost bütün sistem bileşenleriyle hesaplanmalıdır.

Küçük Dosya Sayısının Maliyete Etkisi

Milyonlarca tiny object toplamda az veri tutsa bile çok sayıda request oluşturabilir. Her upload, read ve list operation maliyeti birikir. Metadata yönetimi ve inventory süreçleri de daha ağır hale gelir. Bazı log veya telemetry kullanımında küçük kayıtları archive dosyası içinde toplamak avantajlı olabilir. Buna karşılık random access gereksinimi aggregation kararını etkiler.

Milyonlarca Tiny Object

Her telemetry event'i ayrı object yapmak kolay görünebilir. Ancak milyonlarca key listeleme ve request maliyetini büyütür. Günlük partition dosyaları daha verimli olabilir. Küçük object modeli event consumer sayısını da artırabilir. Veri erişim ihtiyacı tasarımın temel belirleyicisidir.

Operation Cost

Tiny object her yazmada ayrı PutObject üretir. Okuma da ayrı GetObject anlamına gelir. Byte başına request maliyeti büyük object'e göre daha yüksek hale gelebilir. Batch aggregation operation sayısını azaltabilir. Gerçek cost object başına request metric'iyle analiz edilmelidir.

List Operations

Çok büyük key sayısında listing pagination gerektirir. Admin UI için sürekli list yapmak kullanıcı deneyimini yavaşlatabilir. Database index object metadata sorgusunu daha iyi çözebilir. Inventory job prefix ve cursor ile kademeli çalışabilir. List result memory içinde tamamen tutulmamalıdır.

Metadata

Her tiny object metadata taşır. Search veya analytics için object metadata yeterli sorgu modeli sunmaz. Database veya data warehouse ayrı index oluşturabilir. Object key event id ile ilişkilendirilebilir. Metadata duplication kabul edilebilir fakat source-of-truth açık olmalıdır.

Object Aggregation Ne Zaman Mantıklıdır?

Veriler genellikle birlikte okunuyorsa aggregation faydalı olabilir. Günlük logları tek compressed archive içinde tutmak örnektir. Tek kayda random access gerekiyorsa büyük archive uygun olmayabilir. Analytics sistemi partition file okuyabiliyorsa aggregation daha verimli olur. Karar read pattern ve operation cost üzerinden verilmelidir.

Storage Maliyeti Nasıl Otomatik Optimize Edilir?

Storage maliyet optimizasyonu düzenli insan kontrolüne bırakılmak zorunda değildir. Lifecycle eski ve geçici veriyi otomatik yönetebilir. Storage class transition cold data maliyetini azaltabilir. Incomplete upload cleanup görünmeyen storage israfını temizler. Periodic inventory analizi policy'nin gerçekten işe yarayıp yaramadığını gösterir.

Lifecycle

Lifecycle belirli yaştaki object'i otomatik siler veya taşır. Temporary ve archive verileri farklı rule kullanabilir. Manual cleanup unutulması riski ortadan kalkar. Production rule değişiklikleri review edilmelidir. Maliyet düşerken yanlış data deletion oluşmadığı doğrulanmalıdır.

Storage Class Transition

Cold data daha uygun storage class'a geçirilebilir. Access frequency metriği aday object grubunu belirler. Age tek başına her zaman doğru sinyal değildir. Retrieval maliyeti dahil total cost hesaplanmalıdır. Transition sonucu sonraki aylarda fatura üzerinden doğrulanmalıdır.

Incomplete Upload Cleanup

Yarım multipart session'lar görünmeyen storage alanı tüketebilir. Lifecycle belirli süre sonra bunları temizler. Resume ihtiyacı olan kullanıcılar için süre makul tutulmalıdır. Incomplete session count izlenmelidir. Ani artış frontend upload bug'ını gösterebilir.

Temporary Data Expiration

Export, cache ve processing ara dosyaları kalıcı olmak zorunda değildir. Prefix bazlı kısa retention büyük tasarruf sağlayabilir. Business owner dosyanın ne kadar süre gerekli olduğunu belirlemelidir. Kullanıcıya expiration bilgisi gösterilebilir. Database record object silinmesiyle senkronize edilmelidir.

Cache

CDN cache origin read operation sayısını azaltabilir. Hot object'lerde daha büyük kazanç sağlar. Cache hit ratio sürekli izlenmelidir. Immutable key uzun TTL kullanımını kolaylaştırır. Private içerik cache policy'si ayrı tasarlanmalıdır.

Periodic Inventory Analysis

Aylık veya haftalık job object count ve byte dağılımını analiz edebilir. Prefix bazlı storage growth beklenmeyen alanları gösterir. Hiç erişilmeyen eski object grupları transition adayı olabilir. Milyonlarca tiny object ayrı raporlanabilir. Cost optimization ölçüm olmadan yalnızca tahmine dönüşmemelidir.

R2 Metrics ile Neler İzlenmeli?

Storage yönetiminde yalnızca toplam byte görmek yeterli değildir. Object count, Class A ve Class B operation sayıları maliyet davranışını açıklar. Upload request dağılımı sistemin workload yapısını gösterir. Geographic request metric global kullanıcı performansını anlamaya yardımcı olur. Migration döneminde eski ve yeni storage kullanım oranları ayrıca izlenmelidir.

Stored Data

Toplam stored byte zaman içindeki büyümeyi gösterir. Prefix bazlı ayrıştırma mümkünse hangi veri grubunun maliyeti artırdığı anlaşılır. Ani sıçrama yanlış retention veya upload loop gösterebilir. Lifecycle değişikliğinin etkisi birkaç dönem içinde görülebilir. Budget alarmı beklenmeyen büyümede erken uyarı sağlar.

Object Count

Object count tiny object problemini görünür hale getirir. Byte miktarı sabit kalırken object sayısı hızla artabilir. List ve operation maliyeti bundan etkilenebilir. Tenant başına object count quota için kullanılabilir. Silme job'larının sonucu count metriğinde izlenebilir.

Class A Operations

Write ağırlıklı workload upload yoğunluğunu gösterir. Multipart ve copy pipeline operation sayısını artırabilir. Beklenmeyen artış client retry loop gösterebilir. Operation sayısı dosya upload count ile karşılaştırılmalıdır. Cost alarmı bu metriği kullanabilir.

Class B Operations

Read ve metadata request'leri kullanıcı trafik davranışını gösterir. CDN cache değişikliği sonrasında origin request düşüşü beklenebilir. Gereksiz HEAD call'ları yüksek sayı oluşturabilir. Frontend sürüm değişikliği read pattern'i etkileyebilir. Cost ve latency birlikte değerlendirilmelidir.

Upload Requests

Başarılı ve başarısız upload sayısı ayrı izlenmelidir. Dosya boyutu distribution workload hakkında daha fazla bilgi sağlar. Client app version kırılımı bug tespitinde faydalıdır. Çok yüksek cardinality kullanıcı id label yapılmamalıdır. Tenant veya plan segmenti kontrollü sayıda kullanılabilir.

Geographic Request Distribution

Upload'ların hangi bölgelerden geldiği latency analizine yardımcı olur. Yeni pazara açıldığınızda dağılım değişebilir. Uzak kullanıcıların p95 upload süresi ayrı izlenebilir. Local upload veya location kararı bu veriyle değerlendirilir. Privacy açısından gereğinden hassas konum verisi tutulmamalıdır.

Migration Progress

S3'ten R2'ye geçiş sırasında object count ve byte karşılaştırması yapılabilir. Yeni write'ların yüzde kaçı R2'ye gidiyor izlenebilir. Sippy veya bulk migration ilerlemesi raporlanabilir. Missing object sayısı validation metric olmalıdır. Source kapatılmadan önce başarı kriterleri açıkça karşılanmalıdır.

Upload Pipeline İçin Observability

Upload pipeline yalnızca HTTP success rate ile izlenmemelidir. p50 ve p95 upload latency kullanıcı deneyimini gösterir. Multipart retry sayısı network ve part size sorunlarını açıklayabilir. Queue lag processing kapasitesinin yetişip yetişmediğini gösterir. Processing failure rate dosyanın storage'a gelmesiyle business olarak hazır olması arasındaki farkı görünür hale getirir.

Upload Success Rate

Başarılı upload oranı client version ve operation type ile izlenebilir. Single PUT ve multipart ayrı tutulabilir. Ani düşüş CORS veya credential problemine işaret edebilir. Geographic segment bazı ISP sorunlarını gösterebilir. Çok ayrıntılı label cardinality'den kaçınılmalıdır.

Upload Failure Rate

Failure rate hata kategorisine göre ayrılmalıdır. 403, timeout ve network failure aynı problem değildir. Retry sonrası başarılı olan request ayrı metric olabilir. Permanent failure kullanıcı deneyimini daha doğrudan etkiler. Alarm baseline dışı artışta tetiklenmelidir.

p50/p95 Upload Latency

p50 tipik upload deneyimini gösterir. p95 daha yavaş kullanıcı grubunu görünür hale getirir. Dosya boyutu latency karşılaştırmasında mutlaka hesaba katılmalıdır. MB başına süre veya throughput metric eklenebilir. Global kullanıcı bölgeleri ayrı izlenebilir.

File Size

Dosya size histogramı workload kapasitesini anlamayı sağlar. Çok büyük dosya oranı yükselirse multipart threshold yeniden değerlendirilir. Plan veya tenant bazlı quota davranışı analiz edilebilir. Hata oranı size bucket'larıyla karşılaştırılabilir. Client-reported değil gerçek object size kullanılmalıdır.

Multipart Retry Count

Part retry sayısı network dayanıklılığının önemli göstergesidir. Belirli client version'da yüksek retry bug gösterebilir. Çok küçük part size request sayısını artırabilir. Çok büyük part size tek retry maliyetini yükseltebilir. Metric part duration ile birlikte analiz edilmelidir.

Queue Lag

Queue lag upload sonrası processing bekleme süresini gösterir. Kullanıcı upload'ı bitirse bile dosya uzun süre processing durumda kalabilir. Consumer concurrency artırmak gerekebilir. Tek bir pahalı dosya türü queue'yu yavaşlatıyorsa ayrı queue kullanılabilir. Lag SLO kullanıcı beklentisine göre tanımlanmalıdır.

Processing Failure Rate

Scanner, parser veya thumbnail worker hata verebilir. Failure oranı file type bazında izlenebilir. Permanent invalid file ile infrastructure failure ayrılmalıdır. DLQ büyümesi incident sinyali olabilir. Processing başarısız dosya public duruma geçmemelidir.

Upload Başarısızlıkları Nasıl İzlenir?

Upload hataları kullanıcıya yalnızca genel hata olarak gösterilirse kök neden bulmak zorlaşır. HTTP status, signature error, CORS ve network timeout ayrı kategoriler olmalıdır. Client telemetry upload id ile backend loguna bağlanabilir. Hassas presigned URL loglanmamalıdır. Alerting yalnızca yüksek hata oranında değil belirli kritik error türlerinde de çalışabilir.

HTTP Status Codes

Status code ilk hata sınıflandırmasını sağlar. 4xx genellikle client, signature veya permission problemi olabilir. 5xx geçici servis sorunu gösterebilir. Network failure hiç HTTP response üretmeyebilir. Metric bütün kategorileri tek failure oranına da toplamalıdır.

403

403 authorization veya signature sorununa işaret edebilir. Presigned URL süresi dolmuş olabilir. Yanlış credential veya bucket scope da sebep olabilir. CORS hatası ile karıştırılmamalıdır. Backend logunda upload session ve object key bilgisi incelenebilir.

SignatureDoesNotMatch

Signature mismatch endpoint, header veya request canonicalization farkından kaynaklanabilir. Client imzalanmayan header eklemiş olabilir. Server clock ve expiration kontrol edilmelidir. SDK ile URL üretmek manuel implementasyona göre hatayı azaltır. Hata mesajı client'a secret ayrıntısı göstermemelidir.

CORS Failure

Browser console CORS error gösterebilir. Asıl HTTP request storage'a ulaşmış olsa bile response JavaScript'e açılmayabilir. AllowedOrigins ve methods kontrol edilmelidir. Preflight response network panelinden incelenebilir. CORS düzeltmesi authentication politikasını gevşetmemelidir.

Timeout

Timeout büyük dosya veya yavaş bağlantıda görülebilir. Part size çok büyükse risk artabilir. Retry ve resumability kullanıcı deneyimini iyileştirir. Backend presigned URL expiration süresi upload başlamasına yeterli olmalıdır. Timeout metric file size ile korele edilmelidir.

Connection Failure

Client geçici internet kesintisi yaşayabilir. Browser offline event kullanılarak retry bekletilebilir. Hemen tekrar tekrar request göndermek doğru değildir. Exponential backoff uygulanmalıdır. Multipart session bağlantı geldikten sonra devam ettirilebilir.

Alerting

Upload failure oranı belirli eşik üzerinde alarm oluşturabilir. Signature hatalarının aniden artması deployment problemi gösterebilir. Geographic tek bölgede failure ISP veya routing sorunu olabilir. Alert gerekli context'i taşımalı fakat secret içermemelidir. Incident dashboard son deploy bilgisiyle ilişkilendirilebilir.

R2 Object Listeleme

Object listing yönetim işleri için faydalıdır fakat kullanıcı arayüzü veritabanı sorgusunun yerine geçmemelidir. Büyük bucket mutlaka pagination ve prefix kullanmalıdır. Cursor ile sayfalar kademeli alınır. Arama, permission ve sıralama ihtiyacı için relational database daha uygundur. Object key ile database record arasında ilişki kurmak hibrit tasarımı güçlendirir.

ListObjectsV2

S3 ekosisteminde list operations yaygın olarak bucket object'lerini sayfalı getirir. R2 S3 uyumlu kullanımda benzer pattern uygulanabilir. Sonuçların tamamını memory'ye almak büyük bucket'ta risklidir. Prefix ve pagination kullanılmalıdır. Inventory job rate limit ve cost etkisini hesaba katmalıdır.

Prefix

Prefix arama alanını belirli key grubu ile sınırlar. Tenant veya tarih partition bunun için kullanışlıdır. Bütün bucket'ı taramak yerine yalnızca ilgili bölge listelenir. User id client input'undan değil authorization context'ten türetilmelidir. Prefix naming standardı listeleme kodunu sadeleştirir.

Pagination

Binlerce veya milyonlarca object tek response içinde alınmamalıdır. Pagination memory ve request süresini kontrol altında tutar. Background job her sayfayı işleyip cursor ile devam edebilir. İşlem state'i crash sonrası resume için saklanabilir. Page size cost ve throughput dengesine göre seçilmelidir.

Cursor

Cursor bir sonraki liste sayfasının konumunu temsil eder. Job cursor bilgisini durable state içinde saklayabilir. Retry aynı cursor'dan devam edebilir. Cursor formatı client business logic tarafından yorumlanmamalıdır. API tarafından verilen opaque değer olarak ele alınmalıdır.

Çok Büyük Bucket'larda Listeleme

Büyük bucket inventory işlemi saatler sürebilir. Prefix partition ile iş paralelleştirilebilir. Çok yüksek concurrency operation rate'i gereksiz artırabilir. Günlük incremental index oluşturmak daha verimli olabilir. User-facing arama için doğrudan bucket list kullanılmamalıdır.

UI İçin Database Index Kullanmak

Kullanıcı dosya listesinde filename, tarih ve processing state ile filtreleme isteyebilir. Object storage bu query'ler için tasarlanmamıştır. Database object metadata'yı indexleyebilir. UI cursor pagination doğrudan database üzerinden çalışır. Download gerektiğinde object key R2 erişimine dönüştürülür.

Metadata R2'de mi Database'de mi Tutulmalı?

Teknik object metadata R2 üzerinde tutulabilir. Kullanıcı, permission ve processing state gibi business bilgiler için database daha uygun seçimdir. Searchable metadata indekslenebilir alan gerektirir. Object key iki sistemi birbirine bağlayan foreign reference gibi kullanılabilir. Bu hibrit model object storage'un güçlü yanlarını database query kabiliyetiyle birleştirir.

Object Metadata

Content type veya basit origin bilgisi object metadata içinde tutulabilir. Metadata object ile birlikte taşınır. Sık güncellenen business state için uygun olmayabilir. Arama ve filtreleme yeteneği sınırlıdır. Büyük metadata yerine database kullanılmalıdır.

User ID

User ownership database record üzerinde tutulmalıdır. Object key user prefix içerse bile tek authorization source olmamalıdır. Kullanıcı silindiğinde ilişkili object'ler database sorgusuyla bulunabilir. Public object'te user id key içinde görünür olmamalıdır. Internal surrogate id tercih edilebilir.

Original Filename

Original filename kullanıcı arayüzünde gösterilmek için database'de tutulabilir. Storage key benzersiz UUID olabilir. Filename sanitize edilmelidir. Download response Content-Disposition header oluştururken güvenli encoding kullanılmalıdır. Aynı kullanıcı aynı filename'i birden fazla kez upload edebilir.

Processing State

uploaded, scanning ve active gibi state değerleri sık değişebilir. Database bu workflow için daha uygundur. Event consumer state'i atomic update ile değiştirir. UI object storage'ı sorgulamak yerine database state'i kullanır. Failed processing dosyası public erişime açılmaz.

Permissions

Dosya kimlerle paylaşılabilir bilgisi relational yapıya ihtiyaç duyabilir. User, team ve role ilişkileri database'de tutulabilir. Object storage ACL modeli business permission'ın yerine geçmemelidir. Backend her download request'inde database authorization yapabilir. Cache permission context'i doğru dikkate almalıdır.

Searchable Metadata

Tag, title veya extracted text arama için index gerektirir. Object metadata bu amaçla verimli değildir. Relational database veya search engine daha uygun olur. R2 yalnızca binary source olarak kullanılır. Search sonucu object key üzerinden download workflow'una bağlanır.

R2 + Relational Database Pattern

R2 binary dosyayı, database ise metadata ve ilişki bilgisini tutar. Upload session önce database record oluşturabilir. Object key bu record ile eşleştirilir. Event consumer processing sonucunu database'e yazar. Reconciliation iki sistem arasındaki farkları periyodik kontrol eder.

R2'yi Dosya Veritabanı Gibi Kullanmak Doğru mudur?

R2 dosya saklamak konusunda güçlüdür fakat ilişkisel query motoru değildir. Object key üzerinden hızlı erişim sağlar. Metadata arama, join ve karmaşık permission sorguları için database gerekir. Bu nedenle storage'u database yerine kullanmaya çalışmak uygulama kodunu zorlaştırabilir. Hibrit tasarım çoğu production sisteminde daha sağlıklı sonuç verir.

Object Storage'un Güçlü Yönleri

Büyük binary verileri uygun maliyetle saklamak temel avantajdır. Uygulama instance diskinden bağımsızdır. S3 ekosistemi birçok tool ve SDK sunar. Lifecycle ve event automation operasyonu kolaylaştırır. Büyük veri hacmi için yatay ölçek mantığı uygundur.

Query Eksikliği

Object storage SQL benzeri query sistemi sunmaz. Dosyaları kullanıcı adı veya tag ile filtrelemek doğrudan kolay değildir. Prefix yalnızca key başlangıcına göre gruplama sağlar. Complex search için ayrı database gerekir. UI ihtiyaçları storage tasarımını database yönüne taşımamalıdır.

Metadata Search

Searchable metadata relational veya search index içinde tutulmalıdır. Object key source binary'yi işaret eder. Event processing extracted metadata'yı database'e yazabilir. Arama sonucunda kullanıcı authorization kontrolü yapılır. Sonra download URL üretilir.

Database ile Hybrid Tasarım

Hybrid model iki sistemin güçlü yanlarını kullanır. Database transaction ve query sağlar. R2 yüksek hacimli binary data tutar. Object key ilişki alanı görevi görür. Reconciliation eventual consistency sorunlarını yönetir.

Otomatik Backup'ları R2'ye Yükleme

Cloudflare R2 otomatik yedekleme erişim anahtarı ve bucket güvenliği, yalnızca bir cron komutundan daha kapsamlı düşünülmelidir. Database dump alınmalı, sıkıştırılmalı, gerektiğinde şifrelenmeli ve checksum ile doğrulanmalıdır. Upload başarısızlığında alarm üretilmelidir. Lifecycle eski backup'ları retention politikasına göre silebilir. En önemli kontrol ise backup'ın gerçekten restore edilebildiğini düzenli olarak test etmektir.

Database Dump

Backup pipeline tutarlı database dump oluşturmalıdır. Transaction veya snapshot seçeneği veritabanı motoruna göre belirlenir. Dump başarıyla bitmeden upload başlamamalıdır. Exit code kontrol edilmelidir. Dosya adı database, tarih ve backup id bilgisi taşıyabilir.

Compression

Text tabanlı database dump yüksek oranda sıkıştırılabilir. Daha küçük dosya storage ve upload süresini azaltır. Compression CPU kullanımı job süresini artırabilir. Uygun algoritma recovery speed ile dengelenmelidir. Restore script aynı compression formatını desteklemelidir.

Encryption

Hassas backup uygulama tarafında ek encryption kullanabilir. Encryption key storage credential'dan ayrı yönetilmelidir. Aynı sistemde hem dosya hem anahtar saklamak güvenlik avantajını azaltır. Restore prosedürü key erişimini de test etmelidir. Key rotation eski backup'ların açılabilirliğini korumalıdır.

Upload

Backup dosyası S3 API, AWS CLI veya rclone ile R2'ye gönderilebilir. Büyük arşiv multipart upload kullanabilir. Job upload exit code'unu kontrol etmelidir. Object key tarih partition'ı içerebilir. Upload başarısızsa eski local backup hemen silinmemelidir.

Checksum

Backup dosyasının SHA-256 değeri üretilebilir. Upload sonrası object tekrar okunarak veya metadata yöntemiyle doğrulama yapılabilir. Checksum restore öncesinde de kontrol edilmelidir. Hash dosyası ayrı object olarak saklanabilir. Bozuk backup successful state'e geçmemelidir.

Lifecycle

Backup retention 7 günlük, haftalık ve aylık farklı katmanlar içerebilir. Basit age-based lifecycle belirli ihtiyacı çözebilir. Kritik aylık backup daha uzun tutulabilir. Locked retention ransomware veya yanlış silmeye karşı ek koruma sağlayabilir. Policy recovery objective ile uyumlu olmalıdır.

Restore Test

Upload edilen backup'ın işe yaradığı restore ile kanıtlanır. Belirli aralıklarla izole environment'a restore yapılmalıdır. Schema ve application smoke test çalıştırılabilir. Restore süresi recovery objective ile karşılaştırılmalıdır. Başarısız restore incident olarak ele alınmalıdır.

Cron ile R2 Backup Otomasyonu

Cron küçük ve orta ölçekli sunucularda backup otomasyonu için basit bir yöntemdir. Script dump, compression, upload ve cleanup adımlarını sıralayabilir. Her komutun hata kodu kontrol edilmelidir. Loglama ve failure alert olmadan cron job'ın aylarca çalışmadığını fark etmeyebilirsiniz. Retention mümkün olduğunda storage lifecycle ile yönetilmelidir.

Scheduled Script

Backup script belirli saatlerde cron tarafından çalıştırılır. Aynı job'ın üst üste binmesini önlemek için lock kullanılabilir. Script set -e benzeri hata kontrolü kullanabilir. Temporary dosyalar başarılı upload sonrası temizlenir. Backup id bütün log satırlarında ortak bulunabilir.

AWS CLI

AWS CLI S3 uyumlu endpoint ile upload yapabilir. Credential environment veya güvenli config üzerinden verilir. Endpoint parametresi script içinde merkezi tanımlanabilir. Exit code başarının temel sinyalidir. Büyük dosya davranışı CLI sürümüyle test edilmelidir.

rclone

rclone backup dosyalarını R2 remote'a kopyalayabilir. Retry ve transfer seçenekleri otomasyon için kullanışlıdır. sync yerine copy kullanımı veri silme riskini azaltabilir. Eğer sync gerekiyorsa kaynak ve hedef yönü çok dikkatli kontrol edilmelidir. Log output monitoring sistemine gönderilebilir.

Loglama

Job başlangıç ve bitiş zamanı kaydedilmelidir. Dosya boyutu ve object key logda bulunabilir. Secret veya presigned URL yazılmamalıdır. Başarılı upload count ve failure reason ayrı alanlarda tutulabilir. Log retention backup retention'dan farklı olabilir.

Failure Alert

Cron job başarısız olduğunda email veya monitoring alarmı üretmelidir. Sadece stdout'a hata yazmak yeterli değildir. Art arda birkaç failure kritik alarm oluşturabilir. Son başarılı backup zamanı ayrı metric olarak izlenebilir. Belirli süre yeni backup yoksa alarm tetiklenmelidir.

Retention

Local ve remote retention ayrı düşünülebilir. Sunucu diskinde yalnızca son birkaç geçici backup tutulabilir. R2 lifecycle daha uzun arşivi yönetir. Restore politikası hangi backup'ların korunacağını belirler. Storage maliyeti retention süresiyle birlikte hesaplanmalıdır.

systemd Timer ile R2 Upload Otomasyonu

systemd timer, Linux sunucularda cron'a alternatif daha kontrollü scheduled job mekanizması sunar. Service unit backup script'i çalıştırır. Timer çalışma zamanını belirler. journald loglama ve service state görünürlüğü sağlar. Retry ve dependency davranışı daha açık biçimde yapılandırılabilir.

Backup Service

Backup logic ayrı systemd service unit içinde tanımlanabilir. Service özel kullanıcıyla çalıştırılabilir. Credential yalnızca bu kullanıcıya açık environment file içinde tutulabilir. Resource limit uygulanabilir. Exit status systemd tarafından takip edilir.

Timer

Timer service'in ne zaman çalışacağını tanımlar. Persistent ayarı sunucu kapalıyken kaçırılan işlerin yeniden çalışmasına yardımcı olabilir. Schedule UTC veya local timezone beklentisine göre belirlenmelidir. Aynı job overlap olmamalıdır. systemctl list-timers operasyon kontrolünü kolaylaştırır.

Credential

Secret unit dosyası içine doğrudan yazılmamalıdır. Environment file veya secret manager kullanılabilir. File permission dar tutulmalıdır. Rotation sonrası service restart gerekebilir. Backup token yalnızca ilgili bucket write erişimine sahip olmalıdır.

Retry

Service failure durumunda systemd restart politikası kullanılabilir. Ancak script idempotent olmalıdır. Aynı backup file tekrar upload edildiğinde duplicate key oluşmaması sağlanabilir. Exponential delay için wrapper logic gerekebilir. Permanent credential hatasında sonsuz restart yapılmamalıdır.

journald

Service logları journald üzerinden merkezi görüntülenebilir. Backup id ve object key log mesajlarında bulunabilir. Secret değerleri loglanmamalıdır. Log forwarding sistemi alert üretmek için kullanılabilir. Disk log retention ayrıca yapılandırılmalıdır.

Cron'dan Farkı

systemd service state ve dependency yönetiminde daha fazla kontrol sunar. Cron ise daha basit ve yaygındır. Küçük tek script için cron yeterli olabilir. Kritik backup işlerinde systemd observability avantajı sağlayabilir. Ekip hangi mekanizmayı daha güvenilir işlettiğini değerlendirmelidir.

CI/CD Artifact'larını R2'de Saklama

Build artifact, release archive ve test raporları CI pipeline tarafından R2'ye otomatik yüklenebilir. Object key commit, release ve pipeline id içerebilir. Immutable key overwrite riskini azaltır. Lifecycle eski branch artifact'larını belirli süre sonra silebilir. Production release artifact'ları daha uzun retention ve daha dar permission kullanabilir.

Build Artifact

Compiled binary veya bundle build sonunda upload edilebilir. Key commit SHA ve build id içerebilir. Aynı build tekrar çalışırsa idempotency yaklaşımı kullanılabilir. Artifact checksum release doğrulamasında faydalıdır. Temporary branch build'leri kısa retention alabilir.

Release Archive

Release package daha uzun süre saklanması gereken artifact olabilir. Version numarası immutable key içinde yer almalıdır. Overwrite engellenmesi tavsiye edilir. Rollback sırasında eski release hızlı erişilebilir olmalıdır. Bucket lock kritik release arşivinde değerlendirilebilir.

Source Map

Source map debug için gerekli fakat hassas source bilgisi içerebilir. Public asset ile aynı bucket veya domain'de tutulmaması gerekebilir. Error monitoring servisi private erişimle kullanabilir. Retention release support süresine göre seçilebilir. Build silinse bile ilgili production release source map korunmalıdır.

Test Report

Test report ve coverage çıktıları pipeline artifact olarak saklanabilir. JSON veya HTML dosyaları ayrı prefix altında tutulabilir. Pull request artifact'ları kısa süre sonra silinebilir. Release test raporları daha uzun retention alabilir. Database veya CI metadata object key ile ilişkilendirilebilir.

Retention Rule

Artifact türüne göre farklı lifecycle rule uygulanabilir. Feature branch output birkaç gün sonra temizlenebilir. Main release arşivi aylarca saklanabilir. Prefix bu ayrımı desteklemelidir. Policy CI ekibi ve release süreciyle birlikte tanımlanmalıdır.

GitHub Actions / GitLab CI Upload

CI runner S3 uyumlu client veya rclone kullanarak R2'ye upload yapabilir. Credential CI secret store içinde tutulmalıdır. Pull request'ten gelen untrusted kodun production credential'a erişmemesi gerekir. Environment protection rule kullanılabilir. Upload tamamlandıktan sonra artifact checksum doğrulanabilir.

Log Arşivlerini R2'ye Gönderme

Uygulama loglarının uzun süreli arşivi object storage için uygun workload'dur. Log dosyaları günlük partition ve compression ile saklanabilir. Eski loglar Infrequent Access politikasına geçirilebilir. Retention güvenlik ve mevzuat ihtiyacına göre belirlenmelidir. Analytics pipeline bu archive dosyalarını toplu olarak okuyabilir.

Application Logs

Runtime logları önce local veya streaming log platformunda toplanabilir. Günlük archive job R2'ye batch dosya gönderebilir. Her log satırını ayrı object yapmak verimsiz olabilir. JSONL veya compressed file formatı kullanılabilir. Hassas kullanıcı verisi loglamadan önce filtrelenmelidir.

Daily Partition

logs/service/yyyy/mm/dd/ key yapısı tarih bazlı organizasyon sağlar. Belirli gün kolayca listelenebilir. Lifecycle age üzerinden çalışsa da partition incident analizini kolaylaştırır. Timezone standardı UTC olabilir. Service ve environment bilgisi prefix içinde yer alabilir.

Compression

Text loglar yüksek oranda sıkıştırılabilir. Gzip veya benzeri format storage miktarını azaltır. Analytics tool format desteğiyle uyumlu seçim yapılmalıdır. Çok büyük tek archive yerine makul chunk'lar kullanılabilir. Compression CPU job penceresinde hesaba katılmalıdır.

Infrequent Access

Yeni loglar incident araştırması için daha sık okunabilir. Belirli süre sonra access oranı düşer. Lifecycle eski logları IA'ya geçirebilir. Büyük incident sırasında retrieval maliyeti artabilir. Bu trade-off cost planında dikkate alınmalıdır.

Retention

Log retention güvenlik soruşturması ve mevzuat gereksinimine bağlıdır. Her log türü aynı süre tutulmamalıdır. Debug log daha kısa yaşayabilir. Audit log daha uzun saklanabilir. Bucket lock gerekiyorsa ilgili prefix veya bucket politikası değerlendirilmelidir.

Analytics Pipeline

Archive loglar batch analytics job tarafından okunabilir. Object key tarih ve servis filtresi sağlar. Processing sonucu data warehouse'a yazılabilir. Aynı archive tekrar işlenmemesi için manifest tutulabilir. Büyük dataset scanning retrieval maliyetiyle birlikte planlanmalıdır.

AWS S3'ten Cloudflare R2'ye Geçiş

S3 uyumluluğu migration işini kolaylaştırabilir ancak endpoint değiştirmek bütün geçişin tamamlandığı anlamına gelmez. API compatibility, metadata ve application davranışı test edilmelidir. Data migration sonrası object count ve checksum doğrulaması yapılmalıdır. Cutover sırasında yeni write'ların hangi storage'a gittiği açık biçimde yönetilmelidir. Rollback planı source tamamen kapatılmadan önce hazır tutulmalıdır.

S3-Compatible Endpoint

Mevcut S3 client R2 endpoint'ine yönlendirilebilir. Credential seti değiştirilir. SDK code büyük ölçüde aynı kalabilir. Özel S3 feature kullanılıyorsa compatibility ayrıca test edilmelidir. Integration test gerçek production operation setini kapsamalıdır.

Credential Değişikliği

AWS credential yerine R2 erişim anahtarı kullanılır. Environment secret'ları ayrı tutulmalıdır. Migration döneminde iki storage credential aynı uygulamada bulunabilir. Bu durum secret exposure alanını büyüttüğü için geçici tutulmalıdır. Cutover sonrası eski credential kaldırılmalıdır.

API Compatibility Kontrolü

Uygulamanın kullandığı Put, Get, multipart ve presign davranışları test edilmelidir. Storage provider'ın her özel S3 özelliğini desteklediği varsayılmamalıdır. Error code ve metadata farkları incelenebilir. Performance benchmark eski sistemle karşılaştırılabilir. Compatibility matrix proje dokümanında tutulabilir.

Data Migration

Mevcut object'ler bulk veya lazy migration ile taşınabilir. Büyük dataset için paralel transfer gerekir. Source ve target object size karşılaştırılabilir. Metadata ve content type korunmalıdır. Migration job retry ve resume desteklemelidir.

Validation

Object count tek başına yeterli doğrulama değildir. Sample veya bütün dataset için checksum karşılaştırması yapılabilir. Random file download testleri çalıştırılabilir. Metadata ve public URL davranışı doğrulanmalıdır. Validation başarı kriterleri migration başlamadan tanımlanmalıdır.

Cutover

Yeni write'lar belirli noktada R2'ye yönlendirilir. Read path önce R2, bulunamazsa source fallback kullanabilir. Migration tamamlandıkça fallback oranı düşer. Error ve latency metric yakından izlenir. Source ancak validation ve rollback penceresi tamamlandıktan sonra devreden çıkarılır.

R2 Sippy Nedir?

Sippy migration sırasında object'i ihtiyaç anında kaynaktan alıp R2'ye taşımaya yardımcı olan lazy migration yaklaşımıdır. Bütün dataset'i cutover öncesinde taşımak zorunda kalmazsınız. Object ilk talepte source'tan alınır ve R2'ye kopyalanabilir. Bu model upfront transfer süresini azaltır. Buna karşılık hiç erişilmeyen eski object'lerin ayrıca bulk migration ile taşınması gerekebilir.

On-Demand Migration

Object yalnızca ihtiyaç olduğunda migrate edilir. Hot data doğal olarak önce R2'ye gelir. Cold object için gereksiz ilk transfer yapılmaz. Cutover daha hızlı gerçekleştirilebilir. Source erişilebilir kalmak zorundadır.

Object İlk İstendiğinde Kaynaktan Alma

R2'de bulunmayan object read sırasında source storage'dan alınır. Kullanıcı ilk erişimde biraz daha yüksek latency görebilir. Sonraki request R2 üzerinden cevaplanabilir. Source failure migration sürecinde kullanıcı erişimini etkileyebilir. Monitoring fallback hit oranını göstermelidir.

Aynı Anda R2'ye Copy

Source'tan alınan object aynı zamanda R2'ye yazılır. Böylece tekrar erişimde migration tamamlanmış olur. Metadata korunması kontrol edilmelidir. Copy başarısızsa kullanıcı response'u ve migration state ayrı değerlendirilmelidir. Retry mekanizması gerekli olabilir.

Kademeli Migration

Hot object'ler kullanıcı trafiğiyle doğal olarak migrate olur. Büyük upfront job yükü azalır. Migration progress zaman içinde yavaşlayabilir çünkü cold data hiç erişilmez. Bu noktada bulk tool tamamlayıcı olabilir. Source kapatma kriteri kalan object sayısını da içermelidir.

Upfront Migration Yerine Lazy Migration

Çok büyük dataset'i önceden tamamen taşımak günler sürebilir. Lazy model cutover'ı daha erken yapmayı sağlar. Bunun karşılığında source sistem bir süre daha çalışır. Dual storage operasyonu izlenmelidir. Final aşamada cold data bulk transfer ile tamamlanabilir.

Super Slurper Nedir?

Super Slurper büyük veri setlerini toplu biçimde R2'ye taşımak için bulk migration yaklaşımı sunar. One-time transfer workload'unda kullanılabilir. Çok büyük dataset'i batch halinde taşımak migration süresini kısaltabilir. Sippy ile birlikte kullanıldığında hot ve cold data stratejileri birbirini tamamlar. Validation ve cutover yine uygulama ekibinin sorumluluğundadır.

Bulk Migration

Bulk migration çok sayıda object'i planlı batch olarak taşır. Transfer concurrency kontrollü olmalıdır. Source ve target rate limitleri izlenmelidir. Hata alan object listesi ayrı tutulmalıdır. Job resume özelliği büyük transferlerde önemlidir.

One-Time Transfer

Migration çoğu zaman bir defalık operasyon olarak planlanır. Tool configuration versionlanabilir. Transfer tamamlandıktan sonra credential iptal edilebilir. Validation başarılı olmadan source silinmemelidir. Operasyon raporu toplam byte, object ve failure sayısını içermelidir.

Büyük Dataset

Milyonlarca object bulunan storage elle migrate edilemez. Bulk tool parallel transfer ve retry sağlar. Tiny object workload operation sayısını yükseltebilir. Network bandwidth transfer hızını sınırlayabilir. Migration window gerçek ölçümle tahmin edilmelidir.

Sippy ile Birlikte Kullanım

Sippy hot object'leri demand üzerinden taşır. Bulk migration kalan cold dataset'i tamamlar. Bu kombinasyon cutover süresini azaltabilir. Duplicate object overwrite davranışı açık olmalıdır. Existing object'leri skip etmek gereksiz transferi önler.

Sippy + Super Slurper Migration Stratejisi

İki yaklaşımı birlikte kullanmak büyük migration'larda dengeli çözüm sunar. Önce Sippy ile read fallback açılır ve yeni write'lar R2'ye alınır. Kullanıcı trafiği hot data'yı doğal biçimde migrate eder. Ardından bulk job kalan object'leri taşır. Validation tamamlandıktan sonra source kontrollü biçimde devreden çıkarılır.

Önce Sippy

Read path R2'yi önce kontrol eder. Missing object source'tan alınır. Hot dataset kısa sürede R2'ye taşınır. Kullanıcı migration beklemek zorunda kalmaz. Fallback metric geçiş hızını gösterir.

Yeni Write'ları R2'ye Alma

Cutover sonrasında bütün yeni object'ler doğrudan R2'ye yazılmalıdır. Dual-write uzun süre devam ederse consistency zorluğu yaratır. Source yalnızca eski read fallback olarak kalabilir. Write success metric R2 üzerinden izlenir. Rollback planı gerekiyorsa geçici olarak korunur.

Kalan Veriyi Bulk Migrate Etme

Cold object'ler kullanıcı trafiğinde hiç istenmeyebilir. Bulk transfer bu kalan dataset'i taşır. Prefix bazlı batch uygulanabilir. Error listesi tekrar işlenir. Progress object count ve byte olarak raporlanır.

Existing Objects'i Skip Etme

Sippy'nin önceden taşıdığı object'i tekrar transfer etmek gereksizdir. Bulk job target existence kontrolüyle skip edebilir. Checksum gerekiyorsa yalnızca key varlığı yeterli olmayabilir. Source ve target metadata karşılaştırılabilir. Skip oranı migration verimliliğini gösterir.

Source'u Devreden Çıkarma

Fallback hit sıfıra yaklaşmalı veya kabul edilen eşik altına inmelidir. Validation sample değil kritik dataset üzerinde yeterli güven sağlamalıdır. Son backup alınabilir. Source credential kaldırılır. DNS ve application config migration sonrası sadeleştirilir.

rclone ile R2 Yönetimi

rclone R2 üzerinde copy, sync ve scheduled transfer işlemleri için güçlü bir araçtır. Remote configuration S3 compatible endpoint ile yapılabilir. Büyük dosya transferlerinde retry davranışı yardımcı olur. Sync komutu hedefte silme yapabileceği için dikkatle kullanılmalıdır. Integrity verification ve loglama production otomasyonunda mutlaka eklenmelidir.

Remote Configuration

rclone remote R2 endpoint ve credential bilgisiyle tanımlanabilir. Config file permission dar tutulmalıdır. Production ve staging için ayrı remote isimleri kullanılabilir. Credential repository içine yazılmamalıdır. Remote connection test ile doğrulanmalıdır.

Copy

copy source dosyaları target'a ekler. Hedefte ekstra object varsa silmez. Backup upload için sync'e göre daha güvenli olabilir. Retry ve progress seçenekleri kullanılabilir. Exit code otomasyon tarafından kontrol edilmelidir.

Sync

sync kaynak ve hedefi eşitlemeye çalışır. Yanlış yön seçilirse hedef object'lerin silinmesine yol açabilir. Production öncesinde dry-run kullanılmalıdır. Bucket lock kritik object'i koruyabilir. Scheduled sync için operasyon dokümantasyonu açık olmalıdır.

Large File

Büyük dosya transferlerinde rclone multipart davranışından faydalanabilir. Chunk size ve concurrency ayarları network'e göre değiştirilebilir. Memory kullanımına dikkat edilmelidir. Transfer resume desteği test edilmelidir. Checksum doğrulaması kritik backup'ta ek güven sağlar.

Scheduled Sync

rclone cron veya systemd timer ile düzenli çalıştırılabilir. Job overlap engellenmelidir. Log file merkezi monitoring'e gönderilebilir. Failure sonrası retry sınırlı olmalıdır. Last successful sync metric ayrıca tutulmalıdır.

Integrity Verification

Transfer sonrası object size ve checksum kontrolü yapılabilir. Tool'un hangi hash algoritmalarını kullandığı anlaşılmalıdır. Multipart ETag doğrudan file hash sayılmamalıdır. Kritik dataset için ayrı SHA-256 manifest kullanılabilir. Validation tamamlanmadan source temizlenmemelidir.

R2 Konfigürasyonunu Kod Olarak Yönetme

Production storage config manuel dashboard değişiklikleriyle yönetildiğinde configuration drift oluşabilir. Wrangler ve repository tabanlı config değişiklikleri review sürecine dahil eder. Environment separation dosya veya deployment değişkenleriyle açık hale gelir. Automated deployment insan hatasını azaltır. Delete veya public access gibi kritik değişikliklerde ek approval uygulanabilir.

Wrangler

Wrangler Worker ve R2 entegrasyon config'lerini codebase içinde yönetmeyi kolaylaştırabilir. Development ve production environment'ları ayrı tanımlanabilir. CI aynı komutları tekrarlanabilir biçimde çalıştırır. Secret değerleri config dosyasına yazılmamalıdır. Config değişikliği pull request içinde görünür olur.

Git

Infrastructure config Git history içinde versionlanabilir. Kim hangi lifecycle veya CORS değişikliğini yaptı görülebilir. Rollback için eski config referans alınabilir. Secret değerleri kesinlikle commit edilmemelidir. Code owner approval kritik storage dosyalarına uygulanabilir.

Environment Separation

Dev ve prod aynı config değerlerini kullanmamalıdır. Bucket adları ve allowed origins farklı olabilir. Environment-specific token CI secret store'da bulunur. Production deploy ayrıca approval gerektirebilir. Test config production resource'a işaret etmemelidir.

Review

Lifecycle delete veya bucket access değişikliği en az iki kişi tarafından gözden geçirilebilir. Pull request diff insan tarafından anlaşılır olmalıdır. Rule kapsamı örnek object key'lerle açıklanabilir. Maliyet etkisi büyük değişikliklerde not edilebilir. Review sadece syntax değil business etkiyi de değerlendirmelidir.

Automated Deployment

CI config validation sonrası değişikliği uygulayabilir. Staging deployment önce çalıştırılabilir. Production approval ardından yapılır. Deployment sonucu gerçek resource state ile doğrulanabilir. Hata durumunda otomatik rollback mümkünse uygulanabilir.

Configuration Drift

Dashboard'da manuel değişiklik yapıldığında Git config gerçek sistemden farklı hale gelebilir. Drift detection düzenli olarak remote state'i karşılaştırabilir. Beklenmeyen değişiklik incident veya operasyon uyarısı oluşturur. Acil manual değişiklik daha sonra repository'ye yansıtılmalıdır. Kaynağın hangisi olduğu ekip tarafından açıkça belirlenmelidir.

Lifecycle-as-Code

Lifecycle rule'ları kod olarak tutmak veri silme riskini yönetmek için güçlü bir yöntemdir. Rule değişikliği diff olarak incelenebilir. Production approval özellikle expiration değişikliklerinde önemlidir. Testler örnek object key'lerin hangi rule'a eşleştiğini doğrulayabilir. Böylece storage policy yazılı doküman olmaktan çıkıp tekrarlanabilir altyapı kuralına dönüşür.

Lifecycle Rule Dosyaları

Rule config ayrı dosyada tutulabilir. Her kural id, prefix ve action bilgisi taşır. İnsan okuyabilir format review sürecini kolaylaştırır. Generated config kullanılıyorsa source template de versionlanmalıdır. Dosya lint ve validation testinden geçmelidir.

Version Control

Her lifecycle değişikliği commit history içinde görünür. Incident sırasında eski retention policy bulunabilir. Policy değişiminin nedeni commit mesajında açıklanabilir. Tag veya release ile production config sürümü işaretlenebilir. Manual undocumented değişiklikten kaçınılmalıdır.

Pull Request

Delete rule değişikliği pull request ile tartışılabilir. Reviewer mevcut object kapsamını kontrol eder. Maliyet ve veri kaybı etkisi değerlendirilir. Test sonucu PR içinde gösterilebilir. Approval sonrası deployment otomatik çalışabilir.

Production Approval

Production lifecycle değişikliği ekstra onay gerektirebilir. Özellikle retention kısaltma yüksek risklidir. Legal veya product owner onayı bazı veri türlerinde gerekli olabilir. CI approval olmadan apply yapmamalıdır. Değişiklik sonrası monitoring object deletion trendini izlemelidir.

Yanlış Delete Rule Riskini Azaltmak

Prefix kapsamı deployment öncesinde inventory ile test edilebilir. Kaç object ve byte etkileneceği raporlanabilir. Unexpected büyük sayı deployment'ı durdurabilir. Critical prefix allowlist veya denylist uygulanabilir. İlk uygulamada daha uzun grace period seçilebilir.

CORS-as-Code

CORS ayarlarının dashboard'da manuel tutulması environment farklarını yönetmeyi zorlaştırabilir. Origin listesi kod olarak versionlanabilir. Wildcard kullanımı lint kuralıyla engellenebilir. Staging ve production domain'leri ayrı config alabilir. Automated deployment sonrası gerçek CORS response integration test ile doğrulanabilir.

Origin Listesi

Allowed origins açık dizi olarak config içinde tutulabilir. Her origin neden gerekli olduğu dokümante edilebilir. Eski domain kaldırılmalıdır. Preview domain'lere geniş wildcard vermek yerine controlled pattern veya ayrı environment kullanılabilir. Production liste minimum tutulmalıdır.

Environment Farkları

Localhost yalnızca development config içinde yer almalıdır. Staging kendi domain'ini kullanır. Production liste yalnızca gerçek public application origin'lerini içerir. Bu farklar template variables ile yönetilebilir. Yanlış environment config deployment testinde yakalanmalıdır.

Automated Configuration

CI CORS config'i API üzerinden uygulayabilir. Apply öncesi schema validation yapılır. Deployment sonrasında OPTIONS request test edilir. Hata durumunda önceki config'e rollback düşünülebilir. Secret credential yalnızca deploy job'a verilmelidir.

Wildcard Kontrolü

Lint rule production origin listesinde * kullanımını engelleyebilir. İstisna gerekiyorsa explicit approval istenir. AllowedHeaders wildcard kullanımı da değerlendirilmelidir. Security review config değişikliğinin bir parçası olur. Otomasyon insan hatasını azaltır.

Event Notification-as-Code

Event notification config de infrastructure code olarak yönetilebilir. Hangi queue'nun hangi event ve prefix'i dinlediği repository içinde görünür olur. Consumer deployment ile event routing değişikliği birlikte yapılabilir. Yanlış suffix pipeline'ı tamamen durdurabileceği için integration test önemlidir. Configuration drift düzenli kontrol edilmelidir.

Queue

Event'in gideceği queue config içinde açıkça belirtilir. Production ve staging queue ayrı olmalıdır. Consumer kapasitesi workload'a göre planlanır. Queue adı business function'ı ifade edebilir. Delete veya image pipeline farklı queue kullanabilir.

Event Type

Create ve delete event'leri farklı handler davranışı gerektirir. Config yalnızca gerekli event türlerini seçmelidir. Gereksiz bütün event'leri almak operation ve processing yükünü artırabilir. Multipart completion create pipeline'a bağlanabilir. Lifecycle delete ayrı audit workflow'una gidebilir.

Prefix

Prefix hangi object grubunun event üreteceğini sınırlar. images/ ile backups/ farklı consumer kullanabilir. Naming convention değişikliği event config'i etkiler. CI örnek key ile eşleşme testi yapabilir. Production apply öncesi diff review edilmelidir.

Suffix

Suffix file type routing için kullanılabilir. .jpg veya .pdf belirli consumer'a gidebilir. Gerçek file validation consumer içinde yapılır. Uppercase extension gibi edge case test edilmelidir. Suffix routing security boundary değildir.

Consumer

Consumer queue message'ı işleyen Worker veya servis olabilir. Deployment sırası event producer'dan önce hazır consumer olmasını sağlamalıdır. Yeni event formatı backward compatible tasarlanabilir. Consumer version metric loglarda tutulabilir. Rollback queue message formatını bozmayacak biçimde planlanmalıdır.

CI/CD Deployment

Pipeline önce consumer'ı deploy edip sonra event config'i güncelleyebilir. Integration test örnek object upload edip expected processing sonucunu doğrulayabilir. Production approval kritik routing değişikliğinde kullanılabilir. Failed deployment event kaybına yol açmamalıdır. Config version release artifact olarak saklanabilir.

R2 için Production Security Checklist

Production storage güvenliği tek bir token ayarından oluşmaz. Bucket exposure, credential scope, upload validation ve CORS birlikte kontrol edilmelidir. Direct upload endpoint authentication ve rate limit olmadan yayınlanmamalıdır. File size ve file type sınırı abuse riskini azaltır. Public domain yalnızca gerçekten public content için kullanılmalıdır.

Bucket Varsayılan Olarak Private mı?

Private varsayılan model yanlış veri yayını riskini azaltır. Public access explicit karar olmalıdır. Development test için açılan endpoint production'a taşınmamalıdır. Bucket exposure inventory düzenli taranabilir. Private file download authorization üzerinden yapılmalıdır.

API Token Bucket-Scoped mı?

Token bütün account yerine yalnızca gerekli bucket'a erişmelidir. Runtime write token yönetim yetkisine sahip olmamalıdır. Production ve staging token ayrı olmalıdır. Secret rotation prosedürü bulunmalıdır. Token kullanım audit'i mümkünse izlenmelidir.

Secret'lar Koddan Ayrı mı?

Credential source code içine yazılmamalıdır. CI ve runtime secret store kullanılmalıdır. Local development için güvenli environment file repository dışında tutulabilir. Secret loglara çıkmamalıdır. Sızıntı durumunda rotate işlemi geciktirilmemelidir.

Direct Upload Authentication Var mı?

Presigned URL anonim ve kontrolsüz üretilmemelidir. Backend kullanıcı kimliğini doğrulamalıdır. Tenant ve quota kontrolü yapılmalıdır. URL belirli key ve operation için üretilmelidir. Rate limit abuse davranışını sınırlar.

File Type Validation Var mı?

Extension tek başına yeterli değildir. MIME ve magic byte kontrolü kullanılabilir. Gerekirse malware scanning pipeline çalıştırılır. Allowlist yalnızca işin gerektirdiği formatları kabul eder. Validation başarısız object public olmamalıdır.

File Size Limit Var mı?

Her upload türü için maksimum size belirlenmelidir. Client beyanı upload sonrası gerçek object size ile doğrulanır. Büyük dosya multipart'a yönlendirilebilir. Abuse durumunda quota ve rate limit birlikte çalışır. Limit kullanıcı planına göre farklı olabilir.

Object Key Güvenli mi?

Object key backend tarafından üretilmelidir. Original filename doğrudan key olmamalıdır. Tenant prefix authorization context'ten türetilmelidir. Hassas kişisel veri key içine yazılmamalıdır. UUID veya ULID collision riskini azaltır.

CORS Daraltılmış mı?

Allowed origins yalnızca gerçek application domain'lerini içermelidir. Development localhost production config'te bulunmamalıdır. Method ve header listesi minimum tutulmalıdır. Wildcard kullanımı review gerektirmelidir. CORS authentication yerine geçmemelidir.

Rate Limit Var mı?

Upload permission endpoint yüksek trafikte kötüye kullanılabilir. User, tenant veya IP bazlı limit uygulanabilir. Büyük dosya size quota ile ayrıca sınırlandırılır. Rate limit response kullanıcıya anlaşılır bilgi vermelidir. Abuse spike security alarmı oluşturabilir.

Public Domain Gerekiyor mu?

Her bucket için public domain açmak gereksizdir. Backup ve private documents public olmamalıdır. Public media ayrı bucket veya prefix politikası kullanabilir. Custom domain cache ve WAF avantajı sağlar. Public content yine upload security kontrollerine tabi olmalıdır.

Production Storage Management Checklist

Storage yönetimi upload kodundan sonra bitmez. Lifecycle, multipart cleanup ve retention düzenli olarak doğrulanmalıdır. Storage class policy access pattern'e göre güncellenebilir. Metrics ve cost alert beklenmeyen büyümeyi erken gösterir. Backup ve recovery prosedürü depolanan kritik verinin gerçekten korunup korunmadığını kanıtlar.

Lifecycle Rules

Temporary, logs ve backup prefix'leri için uygun rule bulunmalıdır. Delete rule kapsamı periyodik review edilmelidir. Yeni prefix eklendiğinde lifecycle ihtiyacı değerlendirilir. Rule config version control içinde tutulabilir. Production apply approval gerektirebilir.

Multipart Cleanup

Incomplete multipart session'lar otomatik temizlenmelidir. Cleanup süresi resume kullanımına uygun olmalıdır. Session count metric izlenebilir. Client bug varsa anormal incomplete oranı görülür. Database stale session temizliği ayrıca yapılmalıdır.

Storage Class Policy

Standard ve IA kullanımı gerçek access pattern'e dayanmalıdır. Old age tek başına yeterli sinyal olmayabilir. Retrieval cost aylık analiz edilmelidir. Lifecycle transition sonucu cost değişimi izlenmelidir. Hot object yanlışlıkla IA'ya taşınmamalıdır.

Bucket Lock

Kritik backup ve compliance verisinde lock ihtiyacı değerlendirilmelidir. Retention süresi business policy ile uyumlu olmalıdır. Indefinite lock çok dikkatli kullanılmalıdır. Lifecycle ile etkileşimi test edilmelidir. Lock config değişikliği yüksek riskli operation olarak ele alınmalıdır.

Retention

Her veri sınıfının saklama süresi belgelenmelidir. Product, legal ve security beklentileri ortaklaştırılmalıdır. User deletion request policy ayrıca tanımlanmalıdır. Retention süresi cost modeline dahil edilmelidir. Eski gereksiz object'ler kalıcı hale gelmemelidir.

Metrics

Stored byte, object count ve operation sayıları izlenmelidir. Upload failure ve queue lag storage sağlığını tamamlar. Cost metric prefix veya workload bazında ayrılabilirse faydalıdır. Dashboard yalnızca toplam account verisi göstermemelidir. Alarm threshold historical baseline'a göre belirlenebilir.

Cost Alert

Beklenmeyen storage veya operation artışı bütçe alarmı üretmelidir. Günlük harcama trendi incelenebilir. Multipart retry loop maliyet spike oluşturabilir. Public hot object cache miss problemi read cost artırabilir. Alarm son deployment ile ilişkilendirilebilir.

Backup ve Recovery

Kritik object metadata ve database ilişkisinin backup stratejisi bulunmalıdır. Object storage tek başına application recovery değildir. Database object key kayıtları kaybolursa dosyalar bulunabilir ama ilişki zorlaşır. Restore test bütün sistemi kapsamalıdır. Recovery procedure dokümante edilmelidir.

Production Upload Checklist

Production upload akışı authentication'dan monitoring'e kadar uçtan uca test edilmelidir. Presigned URL scope ve expiration güvenli olmalıdır. Validation ve checksum verinin doğru kabul edilmesini sağlar. Büyük dosyada multipart, retry ve progress kullanıcı deneyimini korur. Event notification ve post-processing dosyanın upload'dan kullanılabilir hale gelmesine kadar olan kısmı otomatikleştirir.

Authentication

Upload session yalnızca doğrulanmış kullanıcıya açılmalıdır. Token expiration akış içinde kontrol edilmelidir. Anonim upload varsa abuse modeli ayrıca tasarlanmalıdır. Authentication logu güvenli audit bilgisi üretir. Kullanıcı kimliği object key içinde gereksiz görünmemelidir.

Presigned URL

URL kısa ömürlü ve tek object key için olmalıdır. Backend authorization sonrasında üretilmelidir. Credential browser'a verilmemelidir. Full URL loglara yazılmamalıdır. Client expiration durumunda yeni session talep edebilir.

Validation

File size, type ve business rule kontrol edilmelidir. Direct upload'da gerçek content processing sonrasında doğrulanır. Quarantine prefix güvenli bekleme alanı sağlar. Invalid object silinir. Validation sonucu database state'e yazılır.

Checksum

Kritik dosya integrity için checksum kullanılabilir. Client hash yalnızca sinyal olabilir. Server verification daha güvenilir sonuç verir. Multipart ETag doğrudan checksum değildir. Hash duplicate detection için de değerlendirilebilir.

Multipart Threshold

Belirli file size üzerinde multipart otomatik devreye girebilir. Threshold gerçek network testine dayanmalıdır. Çok düşük threshold gereksiz request sayısı oluşturur. Çok yüksek threshold büyük single PUT failure maliyetini artırır. Client config merkezi tutulmalıdır.

Retry

Transient network hataları kontrollü retry edilmelidir. Exponential backoff ve jitter kullanılabilir. Permanent 4xx hata tekrar edilmemelidir. Multipart yalnızca başarısız part'ı retry eder. Retry count metric olarak izlenmelidir.

Progress

Frontend kullanıcıya upload yüzdesini göstermelidir. Multipart progress part state'lerinden hesaplanır. Retry sırasında percentage yanlış yükselmemelidir. Upload completion ile processing completion ayrı gösterilebilir. Cancel seçeneği büyük dosyada faydalıdır.

Event Notification

Upload tamamlandığında processing event üretilebilir. Prefix filtreleri doğru consumer'ı seçer. Event duplicate delivery ihtimali kabul edilmelidir. Queue lag izlenmelidir. Event kaybına karşı reconciliation değerlendirilebilir.

Post-Processing

File scan, thumbnail ve metadata çıkarma request path dışında yapılabilir. Consumer idempotent olmalıdır. Başarısız processing DLQ'ya geçebilir. File active olmadan önce gerekli kontroller tamamlanmalıdır. Processing SLO kullanıcı deneyimiyle uyumlu olmalıdır.

Monitoring

Upload success rate ve p95 latency izlenmelidir. Failure type ve retry count ayrı metric olmalıdır. Queue lag ve processing failure dashboard'a eklenmelidir. Stored byte ve operation cost da aynı sistemin parçasıdır. Alarm runbook ile desteklenmelidir.

Uçtan Uca Otomatik R2 Upload Mimarisi

Cloudflare R2 presigned URL multipart upload ve lifecycle yönetimi nasıl yapılır sorusuna en iyi yanıt bütün adımları tek mimari içinde düşünmektir. Kullanıcı authentication ile başlar, backend güvenli key ve presigned URL üretir. Browser doğrudan upload yapar ve event pipeline dosyayı işler. Lifecycle ve storage class uzun vadeli maliyeti yönetir. Metrics ve cost optimization ise sistemin production davranışını sürekli görünür tutar.

1. Kullanıcı Authentication

Kullanıcı upload işleminden önce doğrulanır. Session veya token geçerliliği kontrol edilir. Tenant ve user identity backend context'e eklenir. Public anonymous flow varsa ayrı security policy kullanılır. Authentication başarısızsa storage izni oluşturulmaz.

2. Upload Metadata Gönderimi

Client filename, file size ve content type bilgilerini backend'e gönderir. Bu değerler ön kontrol içindir. Client beyanı gerçek dosya doğrulaması değildir. Quota ve allowlist bu aşamada değerlendirilebilir. Business entity id gerekiyorsa authorization için kullanılır.

3. Backend Authorization

Backend kullanıcının ilgili proje, tenant veya kayda upload yapma yetkisini kontrol eder. Horizontal access testleri burada önemlidir. Quota ve rate limit uygulanır. Yetki başarısızsa object key bile üretilmeyebilir. Audit için request id kaydedilir.

4. Güvenli Object Key Üretimi

Backend tenant, tarih ve UUID kullanarak key oluşturabilir. Original filename key kimliği olarak kullanılmaz. Key immutable tutulursa cache yönetimi kolaylaşır. Database upload record bu key'i saklar. Key kullanıcıya yalnızca gerekli response içinde verilir.

5. Presigned URL Oluşturma

Backend kısa süreli PUT URL imzalar. Scope tek object key ile sınırlıdır. Expiration file size ve network koşuluna uygun seçilir. Gerekli header'lar signature ile tutarlı olmalıdır. API credential client'a verilmez.

6. Browser'dan Direct Upload

Client dosyayı storage'a doğrudan gönderir. Backend bandwidth kullanmaz. Progress kullanıcıya gösterilebilir. Network failure retry edilir. Upload sonucunda object henüz processing bekliyor olabilir.

7. Multipart Gereksinimini Yönetme

Dosya threshold üzerindeyse multipart session oluşturulur. Part size ve concurrency otomatik hesaplanır. Başarısız part yeniden gönderilir. Session state browser veya backend üzerinde tutulur. Incomplete session lifecycle ile temizlenir.

8. Upload Completion

Single PUT success veya multipart complete response storage yazımını tamamlar. Client backend completion endpoint'i çağırabilir. Object size veya HEAD kontrolü yapılabilir. Database state uploaded olarak güncellenir. Processing başlamadan active yapılmaz.

9. R2 Event Notification

Object create event otomasyon sinyali üretir. Prefix ve suffix uygun pipeline'ı seçer. Event payload object key taşır. Aynı event tekrar gelebilir. Event configuration code olarak yönetilebilir.

10. Queue

Queue upload ile processing arasına buffer koyar. Burst traffic consumer'ı doğrudan düşürmez. Retry ve DLQ hata yönetimini sağlar. Queue lag p95 processing süresini etkiler. Farklı file type ayrı queue kullanabilir.

11. Consumer Worker

Worker message'ı alır ve processing lock elde eder. Object'i R2'den okur. File type'a göre gerekli pipeline'ı seçer. Timeout ve retry kontrollü uygulanır. İşlem sonucu database'e yazılır.

12. File Validation / Processing

Magic byte, malware scan veya format kontrolü yapılabilir. Image thumbnail veya PDF parsing çalıştırılabilir. Invalid dosya quarantine'de kalır. Clean dosya verified state'e geçer. Processing sonucu idempotent olmalıdır.

13. Metadata Database Update

Database gerçek size, hash ve processing sonucu ile güncellenir. Searchable metadata burada tutulur. Object key ve ETag kayda eklenebilir. Unique constraint duplicate processing'i engeller. Update failure queue retry ile tekrar denenebilir.

14. Dosyayı Kullanıma Açma

Dosya yalnızca validation başarılıysa active duruma geçer. Public media custom domain üzerinden sunulabilir. Private file authorization gerektirir. User interface processing tamamlandı bilgisini alır. Cache yalnızca güvenli final object üzerinde aktif edilir.

15. Lifecycle ve Storage Class Uygulama

Object prefix ilgili retention politikasına girer. Temporary türevler kısa sürede silinebilir. Cold arşiv IA'ya geçebilir. Locked backup retention süresi boyunca korunabilir. Policy business sınıflandırmasına göre belirlenir.

16. Metrics ve Alerting

Upload success, latency ve retry metric'leri kaydedilir. Queue lag processing sağlığını gösterir. Stored byte ve operation count cost görünürlüğü sağlar. Failure alarmı error category ile tetiklenir. High-cardinality kullanıcı id metric label yapılmaz.

17. Periyodik Cost Optimization

Inventory job storage growth ve access pattern'i analiz eder. Cold object grupları lifecycle transition adayı olabilir. Temporary data retention kısaltılabilir. Cache hit ratio read cost ile karşılaştırılır. Policy değişiklikleri ölçülen sonuçlara göre yapılır.

Cloudflare R2 Kullanırken En Sık Yapılan Hatalar

R2 entegrasyonunda sorunların önemli kısmı storage API'den değil çevresindeki mimari kararlardan çıkar. Credential'ı frontend'e vermek ve public bucket'ı gereksiz açmak ciddi güvenlik hatalarıdır. Büyük dosyada single PUT ve retry eksikliği kullanıcı deneyimini bozar. Lifecycle ve incomplete upload cleanup unutulduğunda maliyet zamanla artar. Migration ve event processing tarafında integrity ve idempotency kontrolleri özellikle önemlidir.

API Credential'ı Frontend'e Vermek

Access key ve secret browser bundle içine asla eklenmemelidir. Kullanıcı developer tools üzerinden bu değeri görebilir. Credential bucket üzerinde geniş yetki sağlayabilir. Presigned URL direct upload için güvenli alternatiftir. Sızmış credential derhal rotate edilmelidir.

Public Bucket'ı Gereksiz Açmak

Private kullanıcı dosyası public endpoint'e ihtiyaç duymaz. Public access en başta kolay görünse de veri sızıntısı riskini artırır. Presigned GET veya Worker proxy kullanılabilir. Public asset için ayrı bucket yönetmek daha açık olabilir. Bucket exposure security checklist içinde düzenli kontrol edilmelidir.

Her Upload'ı Backend Üzerinden Geçirmek

Küçük dosyada backend proxy mantıklı olabilir. Büyük medya ve yüksek traffic'te bandwidth gereksiz artar. Direct upload backend'i veri taşıma işinden çıkarır. Authorization yine backend tarafından yapılır. Architecture file size distribution üzerinden karar vermelidir.

Büyük Dosyalarda Single PUT Kullanmak

Tek uzun request network failure durumunda bütün dosyayı tekrar gerektirir. Kullanıcı yüzlerce megabayt yeniden göndermek zorunda kalabilir. Multipart yalnızca başarısız part'ı tekrar yollar. Resume ve progress deneyimi daha iyi olur. Threshold otomatik uygulanabilir.

Retry Mekanizması Eklememek

Network hataları gerçek kullanıcı ortamında kaçınılmazdır. Tek failure upload'ı kalıcı başarısız yapmamalıdır. Exponential backoff ve jitter kullanılabilir. Permanent hata gereksiz retry edilmemelidir. Retry count metric problemli client sürümünü gösterebilir.

CORS'u * Yapmak

Wildcard development sırasında hızlı çözüm gibi görünür. Production'da gereksiz bütün origin'lere browser erişimi açar. Presigned URL olsa bile attack surface büyür. AllowedOrigins gerçek domain listesi olmalıdır. CORS-as-code wildcard'ı lint ile engelleyebilir.

Client MIME Type'a Güvenmek

Client content type kolayca değiştirilebilir. Extension da güvenlik garantisi değildir. Magic byte ve scanner kullanılabilir. Direct upload file quarantine'e alınabilir. Public serving validation sonucunu beklemelidir.

Original Filename'i Object Key Olarak Kullanmak

Aynı filename overwrite oluşturabilir. Kullanıcı dosya adına beklenmeyen karakterler ekleyebilir. Hassas bilgi URL içinde görünür hale gelebilir. UUID key ve separate original filename metadata daha güvenlidir. Download sırasında kullanıcıya original isim yine gösterilebilir.

Lifecycle Kullanmamak

Temporary ve eski dosyalar sonsuza kadar storage'da kalabilir. Manual cleanup kolayca unutulur. Lifecycle retention işini otomatikleştirir. Rule prefix ve age business policy'ye göre seçilir. Silme değişiklikleri review edilmelidir.

Incomplete Multipart Upload'ları Unutmak

Yarım session part'ları storage tüketebilir. Kullanıcı bu object'leri normal listede görmeyebilir. Lifecycle cleanup uygulanmalıdır. Session count metric bug tespitini sağlar. Resume için gerekli retention süresi korunmalıdır.

Bucket Lock ile Lifecycle Etkileşimini Görmezden Gelmek

Lock silmeyi engellerken lifecycle delete yapmaya çalışabilir. Beklenen cleanup gerçekleşmez. Storage büyümesi maliyet sürprizi yaratır. Policy birlikte test edilmelidir. Compliance retention maliyet planına dahil edilmelidir.

Infrequent Access'ı Her Veri İçin Daha Ucuz Sanmak

Düşük storage fiyatı tek başına yeterli değildir. Sık read retrieval maliyeti oluşturabilir. Minimum storage duration etkisi de vardır. Hot user media Standard'da daha ekonomik olabilir. Access pattern metric'e göre karar verilmelidir.

Operation Cost'u Hesaba Katmamak

Milyonlarca tiny object çok sayıda request oluşturur. Toplam GB düşük olsa bile maliyet yükselebilir. Multipart part size de operation sayısını etkiler. Cache read request sayısını azaltabilir. Cost dashboard request sınıflarını göstermelidir.

Event Consumer'ı Idempotent Tasarlamamak

Queue message tekrar teslim edilebilir. Consumer aynı thumbnail veya notification'ı iki kez üretmemelidir. Object key + ETag unique processing id olabilir. Database constraint ek koruma sağlar. Idempotency distributed pipeline'ın temel gereksinimidir.

Migration Sonrası Veri Bütünlüğünü Kontrol Etmemek

Object sayısının eşleşmesi içeriğin doğru olduğu anlamına gelmez. Size ve checksum validation yapılmalıdır. Metadata ve content type kontrol edilmelidir. Random restore veya download testleri çalıştırılabilir. Source yalnızca validation sonrası kapatılmalıdır.

Cloudflare R2 İçin En İyi Programlama Dili Hangisidir?

R2 için tek bir doğru programlama dili yoktur. JavaScript ve TypeScript Workers ekosistemiyle çok doğal çalışır. Python backup ve data pipeline otomasyonunda güçlüdür. Go yüksek performanslı CLI ve backend servislerinde tercih edilebilir. Asıl önemli konu dil seçiminden çok S3 API, object storage, security ve retry temellerini doğru anlamaktır.

JavaScript ve TypeScript

JavaScript ve TypeScript Cloudflare Workers ile doğrudan uyumludur. Frontend ve backend aynı dil ekosistemini paylaşabilir. AWS SDK üzerinden external S3 API kullanımı da mümkündür. TypeScript upload session ve metadata tiplerini daha güvenli hale getirir. Event consumer ve API kodu aynı repository içinde yönetilebilir.

Cloudflare Workers

Workers authentication, presigned URL üretimi ve processing consumer için kullanılabilir. R2 binding platform entegrasyonunu sadeleştirir. Queue consumer aynı ekosistemde çalışabilir. Server yönetimi gerektirmeden edge uygulama oluşturulabilir. Uzun CPU işlemleri için ayrı processing servisi gerekebilir.

Wrangler

Wrangler local development ve deployment workflow'unu kolaylaştırır. Binding config repository içinde tutulabilir. Environment separation uygulanabilir. CI üzerinden automated deployment yapılabilir. Secret değerler ayrı güvenli kanaldan yönetilmelidir.

AWS SDK

JavaScript S3 client R2 endpoint ile kullanılabilir. Presigned URL ve multipart işlemleri uygulamak kolaylaşır. SDK retry config production ihtiyacına göre gözden geçirilmelidir. Endpoint ve credential environment config'ten alınmalıdır. Kullanılmayan ağır modüller serverless bundle boyutunda değerlendirilebilir.

Python

Python backup, automation ve data engineering işlerinde oldukça uygundur. boto3 S3 uyumlu client yaklaşımı sunar. Cron veya scheduled script hızlı geliştirilebilir. Büyük dataset processing için zengin kütüphane ekosistemi vardır. Web upload API için de kullanılabilir fakat Workers entegrasyonu JavaScript kadar doğal olmayabilir.

boto3

boto3 S3 client endpoint override ile R2'ye bağlanabilir. Put, get ve multipart işlemleri uygulanabilir. Credential environment secret üzerinden verilir. Retry config kontrol edilmelidir. Integration test gerçek R2 bucket ile çalıştırılabilir.

Backup automation

Python database dump pipeline'ını yönetebilir. Subprocess exit code kontrol edilir. Compression ve checksum adımları kolay eklenir. Upload sonrası notification gönderilebilir. Script systemd timer veya cron ile scheduled çalışabilir.

Data pipelines

Dataset ve log processing için Python güçlü araçlar sunar. R2 object'leri batch olarak okunabilir. Metadata database veya analytics sistemine yazılabilir. Büyük data memory içine tamamen alınmamalıdır. Streaming ve partitioning tercih edilmelidir.

Go

Go düşük memory kullanan CLI ve backend servislerinde iyi seçimdir. S3 SDK ile R2 entegrasyonu yapılabilir. Parallel multipart upload worker pool ile kontrol edilebilir. Static binary deployment operasyonu kolaylaştırır. High-throughput migration tool geliştirmek için uygundur.

S3 SDK

Go S3 client custom endpoint ile yapılandırılabilir. Context cancellation network request'lerine taşınabilir. Retry policy merkezi tutulabilir. Multipart concurrency kontrollü uygulanabilir. Benchmark ile memory ve throughput ölçülebilir.

CLI ve backend services

Backup veya migration CLI tek binary olarak dağıtılabilir. systemd service içinde çalıştırmak kolaydır. Backend presigned URL API'si de Go ile geliştirilebilir. Structured logging operasyonu destekler. Configuration environment ve secret store üzerinden alınmalıdır.

PHP

PHP tabanlı web uygulamaları S3 uyumlu filesystem adapter üzerinden R2 kullanabilir. Laravel gibi framework'lerde storage abstraction entegrasyonu kolaylaştırır. Büyük direct browser upload yine presigned URL ile yapılabilir. Backend yalnızca authorization ve metadata yönetebilir. Framework config içinde credential güvenliği korunmalıdır.

Laravel filesystem

Laravel filesystem S3 disk yapılandırmasıyla R2 endpoint'e bağlanabilir. Application object read ve write işlemlerini abstraction üzerinden yapabilir. Presigned URL desteği kullanılan adapter'a göre test edilmelidir. Environment config production ve staging'i ayırır. Büyük file processing queue job'a taşınabilir.

Programlama Dilinden Daha Önemli Olan S3 ve Object Storage Temelleri

Dil syntax'ı öğrenmek R2 sistemini güvenli hale getirmez. Object key, multipart, presigned URL ve lifecycle davranışları asıl temel konulardır. Retry ve idempotency distributed sistem güvenilirliğini belirler. CORS, authentication ve least privilege güvenlik modelini tamamlar. Bu kavramlar anlaşıldığında farklı programlama dillerine geçiş çok daha kolay olur.

Cloud Storage Alanında Yazılımcı Olmak İçin Ne Yapmalı?

Cloud storage alanında ilerlemek için önce HTTP ve API temellerini sağlamlaştırmak gerekir. Ardından object storage ve S3 API davranışlarını pratik projelerle öğrenebilirsiniz. JavaScript, TypeScript veya Python ile upload ve backup otomasyonu geliştirmek iyi başlangıçtır. Event-driven architecture ve security bilgisi production sistemleri anlamanızı sağlar. Observability eklediğinizde yalnızca çalışan değil ölçülebilir ve sürdürülebilir sistemler geliştirmeye başlarsınız.

HTTP Temelleri

GET, PUT, HEAD ve DELETE method'larının anlamını öğrenmek önemlidir. Header, content type ve status code davranışı upload sisteminin merkezindedir. CORS browser HTTP modelinin bir parçasıdır. Range request medya indirmede önem kazanabilir. Network timeout ve retry HTTP bilgisiyle daha doğru tasarlanır.

REST API

Upload session ve metadata endpoint'leri REST API olarak tasarlanabilir. Resource kimliği ve status code kullanımı anlaşılmalıdır. Idempotency key tekrar request yönetiminde önemlidir. Authentication ve rate limit API tasarımının parçasıdır. Storage API ile business API birbirinden ayrılmalıdır.

Authentication

Kullanıcı kimliği güvenilir biçimde doğrulanmalıdır. Session ve token modelleri öğrenilmelidir. Authentication ile authorization arasındaki fark anlaşılmalıdır. Presigned URL yalnızca authentication sonrası üretilebilir. Service-to-service credential yönetimi ayrı bir alandır.

Object Storage

Bucket, object ve key temel kavramlardır. Folder görünümünün prefix olduğunu öğrenmek önemlidir. Lifecycle ve storage class object yaşam döngüsünü yönetir. Metadata query sınırlamaları database ihtiyacını açıklar. Büyük veri sistemleri için object storage düşünce modeli geliştirilmelidir.

S3 API

S3 API birçok object storage ürününde ortak dil gibidir. PutObject, GetObject ve multipart akışı öğrenilmelidir. Signature Version 4 ve presigned URL mantığı önemlidir. CLI ve SDK kullanımı pratik kazanım sağlar. Provider compatibility farkları test yaklaşımını öğretir.

JavaScript/TypeScript veya Python

Bir dili iyi bilmek API entegrasyonunu hızlandırır. TypeScript web ve Worker tarafında güçlüdür. Python automation ve data işlerinde oldukça pratiktir. İlk aşamada iki dili aynı anda öğrenmeye çalışmak gerekmez. Birinde gerçek proje geliştirip storage kavramlarını öğrenmek daha değerlidir.

Cloudflare Workers

Workers serverless request handling mantığını öğretir. R2 binding ile storage entegrasyonu yapılabilir. Queue consumer event-driven processing gösterir. Authentication ve edge routing pratik edilebilir. Küçük open source upload API projesi iyi öğrenme çalışmasıdır.

Queues

Queue request ve ağır processing işini birbirinden ayırır. Retry ve duplicate delivery davranışı öğrenilmelidir. Dead-letter queue production hata yönetimini gösterir. Consumer idempotency kavramı burada çok önemlidir. Backpressure ve queue lag gözlemlenmelidir.

Event-Driven Architecture

Upload tamamlanınca event üretmek event-driven tasarım örneğidir. Producer consumer'ın çalışma detayını bilmez. Queue sistemler arasında gevşek bağlantı oluşturur. Duplicate event ve eventual consistency normal davranışlardır. Reconciliation job güvenilirliği tamamlar.

Security

Least privilege, secret management ve tenant isolation öğrenilmelidir. File upload özel güvenlik riskleri taşır. MIME spoofing ve malware scan gibi konular önemlidir. Public ve private data ayrımı yapılmalıdır. Security yalnızca production sonrasında eklenen özellik olmamalıdır.

Observability

Metric, log ve trace sistemin ne yaptığını görünür hale getirir. Upload p95 latency ve failure rate önemli göstergelerdir. Queue lag processing bottleneck'i açıklar. Operation count maliyet davranışını gösterir. Monitoring olmadan optimizasyon çoğu zaman tahmine dayanır.

Open Source ve İşbirliği ile R2

R2'nin S3 uyumlu yaklaşımı geniş açık kaynak araç ekosisteminden faydalanmayı kolaylaştırır. rclone ve çeşitli SDK'ler hazır entegrasyon parçaları sunar. Backup otomasyonu veya upload library projeleri topluluk katkısı için iyi alanlardır. Ortak Worker template'leri yeni geliştiricilerin öğrenmesini hızlandırabilir. Açık kaynak çalışma aynı zamanda test, dokümantasyon ve güvenlik review pratiği kazandırır.

S3-Compatible Açık Ekosistem

S3 API birçok açık kaynak aracın desteklediği ortak protokoldür. Bu durum provider değiştirmeden önce adapter yaklaşımı geliştirmeyi kolaylaştırır. Tool seçerken yalnızca S3 compatible ibaresine güvenilmemelidir. Gerçek operation test edilmelidir. Open source issue ve contribution süreçleri uyumluluk problemlerini çözmeye yardımcı olabilir.

rclone

rclone backup ve migration için güçlü açık kaynak araçtır. R2 remote oluşturularak test projeleri geliştirilebilir. Dry-run ve loglama davranışı öğrenilebilir. Yeni başlayanlar dokümantasyon veya örnek config katkısı yapabilir. Production sync komutlarında veri silme riskine dikkat edilmelidir.

AWS SDK'leri

S3 SDK'leri birçok programlama dilinde mevcuttur. R2 endpoint kullanarak aynı API modelleri öğrenilebilir. Presign ve multipart örnek projeleri geliştirilebilir. SDK source code retry ve signing davranışını anlamak için incelenebilir. Yeni sürümlerde integration test çalıştırmak faydalıdır.

Open-Source Backup Araçları

Backup tool'ları R2 target desteği eklemek için uygun contribution alanıdır. S3 endpoint config çoğu zaman entegrasyonun başlangıcıdır. Restore ve checksum testleri eklenebilir. Secret management dokümantasyonu önemlidir. Production örnekleri güvenli varsayılanlarla yazılmalıdır.

GitHub Actions

CI artifact upload için reusable action geliştirilebilir. Action R2 endpoint ve secret input alabilir. Credential loglara yazılmamalıdır. Artifact checksum ve retention metadata desteklenebilir. Community projesinde test environment kullanmak güvenli release sağlar.

Ortak Worker Template'leri

Presigned upload API için reusable Worker template geliştirilebilir. Authentication adapter kullanıcı projesine bırakılabilir. Object key güvenli varsayılan üretmelidir. CORS wildcard olmadan örnek config sunulmalıdır. Queue processing template'i ayrı modül olarak eklenebilir.

R2 Upload Library Geliştirme

Browser multipart upload library topluluk için faydalı proje olabilir. Resume, retry ve progress API sunabilir. Backend adapter presigned part URL üretimini kolaylaştırabilir. Security sınırları dokümantasyonda açık belirtilmelidir. Integration test gerçek veya izole storage ortamında çalıştırılabilir.

Diyarbakır Yazılım Topluluğu İçin R2 Proje Fikirleri

R2 odaklı projeler cloud, backend ve frontend bilgilerini aynı çalışmada birleştirmek için oldukça uygundur. Basit file upload service ile başlayıp queue ve lifecycle özellikleri aşamalı eklenebilir. Workshop formatında presigned URL ve multipart upload konuları uygulamalı gösterilebilir. Migration lab gerçek S3 uyumluluğu deneyimi kazandırır. Diyarbakır Yazılım Topluluğu'nun diğer proje çalışmalarını https://www.diyarbakiryazilim.com.tr/projects adresinden inceleyebilirsiniz.

Açık Kaynak File Upload Service

Basit authentication ve presigned URL API'si geliştirilebilir. Frontend direct upload ve progress gösterebilir. Backend metadata'yı relational database'de tutar. Queue thumbnail veya scanner pipeline çalıştırabilir. Proje README'si production security checklist içerebilir.

R2 Backup Automation Projesi

Python veya Bash ile database backup script geliştirilebilir. Compression, checksum ve upload aşamaları otomatik çalışır. Lifecycle retention config örneği eklenebilir. systemd timer veya cron setup belgelenebilir. Restore test komutu projenin önemli parçası olmalıdır.

Presigned URL Workshop

Workshop önce neden credential'ın browser'a verilmemesi gerektiğini anlatabilir. Ardından backend presigned PUT URL üretir. Katılımcılar CORS ve direct upload akışını uygular. URL expiration ve object key güvenliği test edilir. Son bölümde private GET URL eklenebilir.

Event-Driven Image Processing Projesi

Kullanıcı görseli quarantine prefix'e yükler. Event queue consumer'ı tetikler. Worker veya processing service thumbnail üretir. Database status active olur. Frontend processing tamamlandığında yeni görseli gösterir.

R2 + Workers + Queues Atölyesi

Atölye uçtan uca cloud storage mimarisi öğretir. Worker upload izin API'si olur. R2 event queue'ya message gönderir. Consumer metadata işler. Metric ve retry eklenerek production davranışı gösterilir.

S3'ten R2'ye Migration Lab

Katılımcılar küçük test bucket'ını R2'ye taşır. Endpoint ve credential farkı görülür. rclone veya SDK ile migration yapılır. Checksum validation eklenir. Cutover ve rollback senaryosu tartışılır.

Open Source Cloud Storage Contribution Day

Topluluk bir gün boyunca storage odaklı açık kaynak projelere katkı yapabilir. Dokümantasyon, test veya bug fix seçilebilir. Yeni başlayanlar basit issue'larla başlayabilir. Deneyimli geliştiriciler multipart veya retry problemleri üzerinde çalışabilir. Gün sonunda katkılar ve öğrenilen noktalar birlikte değerlendirilebilir.

Portföy İçin Cloudflare R2 Projeleri

Portföy projesi yalnızca dosya yükleme butonu göstermekle sınırlı kalmamalıdır. Authentication, presigned URL, metadata database ve lifecycle eklemek gerçek backend becerisini gösterir. Multipart ve resumable upload daha ileri seviye deneyim sunar. Event-driven PDF veya image processing mimari düşünceyi kanıtlar. Proje README'sinde güvenlik, maliyet ve observability kararlarını açıklamak teknik derinliği artırır.

User-Generated Content Platformu

Kullanıcı profil ve içerik görselleri upload edebilir. Presigned URL direct upload sağlar. Queue scanner ve image optimization çalıştırır. Database ownership ve visibility bilgisini tutar. Public içerik custom domain cache ile sunulur.

Secure File Sharing

Kullanıcı private dosya upload eder. Share link time-limited token üretir. Download backend authorization veya presigned GET kullanır. Revoke özelliği share access'i kapatır. Audit log hangi kullanıcının ne zaman eriştiğini kaydeder.

Image Upload ve Thumbnail Pipeline

Original image quarantine prefix'e gelir. Event consumer image'i doğrular. Birkaç thumbnail boyutu oluşturulur. Database derivative key'leri saklar. Frontend uygun responsive image'i seçer.

Otomatik Backup Sistemi

Scheduled job database dump oluşturur. Dosya compress ve encrypt edilir. R2'ye multipart upload yapılır. Lifecycle retention uygulanır. Ayrı restore test job'ı backup'ın gerçekten kullanılabilir olduğunu doğrular.

Log Archive Platformu

Uygulama logları günlük compressed object olarak R2'ye yazılır. Prefix tarih ve service bilgisi taşır. Eski loglar IA'ya geçer. Search index metadata database üzerinde tutulabilir. Dashboard storage ve operation cost gösterir.

R2 Storage Dashboard

Dashboard object count ve stored byte metric'lerini gösterir. Prefix bazlı maliyet tahmini sunar. Incomplete upload sayısı izlenebilir. Lifecycle rule listesi okunabilir biçimde gösterilir. Cost anomaly alarmı projeye ileri seviye özellik ekler.

Multipart Upload Uygulaması

Browser büyük dosyayı parçalara böler. Backend upload session ve presigned part URL yönetir. Progress ve retry UI'da görünür. Sayfa yenilense bile session resume edilebilir. Cleanup lifecycle incomplete upload'ları siler.

Event-Driven PDF Processing

PDF upload sonrası queue consumer parser'ı çalıştırır. Page count ve text database'e yazılır. Zararlı dosya scanner ile kontrol edilir. Processing state UI'da gösterilir. Search özelliği extracted text üzerinden çalışabilir.

Sonuç: Cloudflare R2 ile Depolama Otomasyonunu Nasıl Sürdürülebilir Hale Getirirsiniz?

Cloudflare R2 ile Otomatik Veri Yükleme ve Depolama Yönetimi, yalnızca bir bucket açıp dosyaları oraya göndermekten çok daha kapsamlıdır. Güvenli object key, presigned URL, multipart retry, lifecycle, event processing ve monitoring aynı mimarinin parçalarıdır. Cloudflare R2 S3 API ile veri yükleme ve depolama yönetimi kurarken özellikle credential scope, file validation ve database metadata tasarımını erken aşamada belirlemek daha sonra yapılacak yeniden düzenlemeleri azaltır. Kurumsal Cloudflare R2 entegrasyonu ve depolama otomasyonu hizmeti kapsamında mevcut upload akışınızın, maliyet yapınızın ve security modelinizin birlikte değerlendirilmesi daha doğru sonuç verir. Diyarbakır Yazılım Topluluğu ve teknik çalışma yaklaşımı hakkında bilgi için https://www.diyarbakiryazilim.com.tr/about adresini inceleyebilirsiniz.

Sık Sorulan Sorular

R2 ile çalışmaya başlayan ekiplerin soruları genellikle upload yöntemi, S3 uyumluluğu, multipart kullanımı ve lifecycle çevresinde yoğunlaşır. Bu soruların çoğunda tek doğru yaklaşım yerine workload'a göre karar vermek gerekir. Büyük dosya ile küçük görsel aynı upload modelini kullanmak zorunda değildir. Benzer biçimde sık okunan kullanıcı medyası ile cold backup aynı storage class politikasına sahip olmamalıdır. Aşağıdaki yanıtlar üretim ortamında karar verirken kullanabileceğiniz pratik çerçeveyi özetler.

Cloudflare R2 nedir?

Cloudflare R2 object storage yaklaşımıyla dosya ve binary veri saklamak için kullanılan bir hizmettir. Veriler bucket içinde object key üzerinden adreslenir. S3 uyumlu API birçok mevcut SDK ve tool ile entegrasyonu kolaylaştırır. Workers binding platform içi erişim sağlar. Lifecycle, event ve storage policy özellikleri otomatik yönetim senaryolarında kullanılabilir.

Cloudflare R2'ye dosya nasıl yüklenir?

Dashboard, Wrangler, Workers binding, S3 SDK, rclone ve AWS CLI gibi farklı yöntemler kullanılabilir. Web uygulamasında backend-controlled veya direct browser upload seçilebilir. Büyük kullanıcı dosyalarında presigned URL ve multipart daha uygun olabilir. Backup job için CLI veya rclone pratik bir çözümdür. Upload yöntemi security ve dosya boyutuna göre seçilmelidir.

R2 AWS S3 ile uyumlu mudur?

R2 yaygın S3 API kullanım kalıplarıyla uyumluluk sağlar. Bu sayede mevcut S3 client ve SDK'leri custom endpoint ile kullanılabilir. Bununla birlikte bütün provider özelliklerinin birebir aynı olduğu varsayılmamalıdır. Uygulamanın kullandığı API çağrıları integration test ile doğrulanmalıdır. Migration öncesinde compatibility checklist hazırlanması faydalıdır.

Presigned URL nedir?

Presigned URL belirli object ve operation için kısa süreli yetki sağlar. Backend kendi API secret'ını client'a vermez. Browser URL üzerinden doğrudan upload veya download yapabilir. URL bearer token gibi korunmalıdır. Key, operation ve expiration mümkün olduğunca dar tutulmalıdır.

R2'ye browser'dan doğrudan dosya yüklenebilir mi?

Evet, presigned URL kullanılarak direct browser upload tasarlanabilir. Backend kullanıcıyı doğrular ve object key üretir. Browser dosyayı R2'ye doğrudan gönderir. CORS policy doğru yapılandırılmalıdır. Upload sonrası validation ve processing queue üzerinden yapılabilir.

R2 upload için CORS nasıl ayarlanır?

AllowedOrigins gerçek application domain'lerini içermelidir. Upload için gereken PUT ve header'lar açıkça izin listesine eklenir. Production ortamında gereksiz wildcard kullanımından kaçınılmalıdır. Preflight davranışı gerçek browser request'i ile test edilmelidir. CORS authentication yerine geçmez.

Cloudflare R2'de maksimum dosya boyutu nedir?

Maksimum object ve upload limitleri platform tarafından belirlenir ve zaman içinde güncellenebilir. Bu nedenle production kararında güncel R2 limits dokümantasyonu kontrol edilmelidir. Büyük object'lerde multipart upload kullanmak daha güvenilir bir yaklaşımdır. Uygulamanın kendi file size limitinin platform maksimumundan daha düşük olması çoğu zaman mantıklıdır. Ürün ve güvenlik ihtiyacı gerçek limiti belirlemelidir.

Multipart upload ne zaman kullanılmalıdır?

Büyük dosya ve kararsız network koşullarında multipart upload güçlü avantaj sağlar. Başarısız part yeniden gönderilebilir. Parallel upload throughput'u artırabilir. Küçük dosyada multipart gereksiz operation maliyeti yaratabilir. Size threshold gerçek workload testine göre seçilmelidir.

R2'de dosyalar otomatik nasıl silinir?

Lifecycle expiration rule belirli yaş veya prefix'e göre object'leri otomatik silebilir. Temporary upload, log ve export verileri için uygundur. Production rule uygulanmadan önce kapsam dikkatle kontrol edilmelidir. Locked object normal lifecycle silmesini engelleyebilir. Database metadata delete event veya reconciliation ile güncellenmelidir.

R2 lifecycle rule nedir?

Lifecycle rule object yaşına veya key grubuna göre otomatik action tanımlar. Expiration, storage class transition ve incomplete multipart cleanup gibi işlemler yapılabilir. Prefix farklı veri türlerine farklı policy uygulanmasını sağlar. Rule config version control içinde tutulabilir. Yanlış delete rule ciddi veri kaybı oluşturabileceği için approval önerilir.

Standard ile Infrequent Access arasındaki fark nedir?

Standard sık erişilen object'ler için daha doğal seçimdir. Infrequent Access daha seyrek okunan veri için maliyet avantajı sağlayabilir. Retrieval ve minimum storage duration etkileri hesaba katılmalıdır. Her eski object otomatik olarak cold sayılmamalıdır. Access pattern metric'leri storage class kararını desteklemelidir.

R2'de egress gerçekten ücretsiz midir?

R2'nin internet veri çıkışı modeli önemli avantaj sağlayabilir. Bununla birlikte storage ve object operation maliyetleri devam eder. Infrequent Access kullanılıyorsa retrieval maliyeti ayrıca oluşabilir. Zero egress ifadesi bütün R2 kullanımının ücretsiz olduğu anlamına gelmez. Total cost storage, operation ve processing birlikte hesaplanmalıdır.

Bucket Lock nedir?

Bucket Lock object'in belirli süre silinmesini veya değiştirilmesini engelleyen retention kontrolüdür. Backup ve compliance verisi için değerlendirilebilir. Lifecycle delete locked object üzerinde beklenen zamanda çalışmayabilir. Lock süresi yanlış seçilirse storage gereksiz uzun tutulabilir. Production config dikkatli approval sürecinden geçmelidir.

Upload sonrası otomatik işlem nasıl başlatılır?

Object create event R2 event notification üzerinden queue'ya gönderilebilir. Consumer Worker message'ı alıp processing başlatır. Thumbnail, scan veya metadata çıkarma yapılabilir. Database state işlem sonucuna göre güncellenir. Consumer duplicate event'e karşı idempotent olmalıdır.

R2 Event Notifications nasıl çalışır?

Object create ve delete gibi storage olayları downstream otomasyonu tetikleyebilir. Prefix ve suffix filtreleri yalnızca ilgili object'leri seçer. Queue producer ile consumer arasında güvenilir buffer sağlar. Retry ve DLQ processing hatalarını yönetir. Event delivery duplicate olabileceği için iş mantığı idempotent tasarlanmalıdır.

R2 ile AWS S3'ten veri nasıl taşınır?

S3-compatible endpoint migration kodunun önemli bölümünü koruyabilir. rclone, bulk migration araçları veya lazy migration yaklaşımı kullanılabilir. Yeni write'lar R2'ye alındıktan sonra cold data batch olarak taşınabilir. Object count, size ve checksum doğrulanmalıdır. Source storage validation tamamlanmadan kapatılmamalıdır.

Sippy nedir?

Sippy object'i ilk erişimde source storage'dan alıp R2'ye taşımaya yardımcı olan migration yaklaşımıdır. Büyük dataset'i cutover öncesinde tamamen migrate etmek zorunda kalmazsınız. Hot object'ler trafik geldikçe R2'ye geçer. Cold object'ler için sonradan bulk migration gerekebilir. Source sistem migration tamamlanana kadar erişilebilir kalmalıdır.

R2 için JavaScript mi Python mı kullanılmalıdır?

İki dil de R2 entegrasyonu için uygundur. JavaScript ve TypeScript Workers ve web upload API'lerinde doğal seçimdir. Python backup, automation ve data pipeline tarafında oldukça güçlüdür. Dil yerine S3 API, security, retry ve object storage temellerine hâkimiyet daha önemlidir. Projenizin mevcut ekosistemi genellikle en doğru dili belirler.

Ek Sık Sorulan Sorular

Cloudflare R2 ve bulut depolama danışmanlığı yakınımda gibi aramalar yapan ekipler çoğu zaman yalnızca teknik API entegrasyonu değil, production mimarisi konusunda da yönlendirmeye ihtiyaç duyar. Güvenli upload, otomatik backup ve lifecycle yönetimi aynı storage stratejisinin parçalarıdır. Her sistemin kullanıcı sayısı, file size dağılımı ve compliance ihtiyacı farklı olduğu için hazır tek bir config bütün projelere uygulanmamalıdır. En iyi sonuç mevcut uygulamanın traffic ve veri sınıflandırması incelendikten sonra alınır. Aşağıdaki sorular bu değerlendirmede en sık karşılaşılan pratik konuları özetler.

Cloudflare R2 ile otomatik veri yükleme süreçleri nasıl oluşturulur?

İlk olarak upload kaynağının browser, backend, backup job veya başka servis olup olmadığı belirlenmelidir. Browser için presigned URL, scheduled backup için CLI veya rclone ve backend servisleri için S3 API kullanılabilir. Upload tamamlandıktan sonra event notification ile queue processing başlatılabilir. Lifecycle eski ve temporary object'leri otomatik yönetir. Monitoring başarı oranı, latency ve storage büyümesini sürekli takip eder.

Cloudflare R2’ye AWS CLI, rclone veya S3 uyumlu API kullanılarak dosyalar nasıl otomatik yüklenir?

R2 için S3 compatible endpoint ve sınırlı erişim credential bilgileri oluşturulur. AWS CLI veya rclone bu endpoint'e yönlendirilir. Scheduled script dosyayı hazırlayıp upload komutunu çalıştırır ve exit code kontrol eder. S3 SDK kullanan uygulama aynı işlemi programatik biçimde yapabilir. Credential değerleri source code yerine güvenli secret store içinde tutulmalıdır.

Büyük dosyalarda multipart upload ve otomatik yeniden deneme süreçleri Cloudflare R2 üzerinde nasıl yönetilir?

Dosya belirli boyutu aştığında multipart session oluşturulur ve içerik part'lara ayrılır. Parçalar sınırlı concurrency ile paralel gönderilebilir. Geçici hatada yalnızca başarısız part exponential backoff ve jitter ile yeniden denenir. Part ETag bilgileri completion request için saklanır. Yarım kalan session'lar lifecycle cleanup ile belirli süre sonra otomatik temizlenir.

Cloudflare R2’de Lifecycle Rules, Event Notifications ve depolama politikaları kullanılarak veri yönetimi nasıl otomatikleştirilir?

Lifecycle temporary ve eski veriyi yaş veya prefix'e göre silebilir ya da farklı storage class'a taşıyabilir. Event Notifications upload ve delete işlemlerini queue consumer'larına iletir. Consumer processing, malware scan ve database metadata update gibi işleri çalıştırır. Bucket Lock gerektiğinde belirli verinin silinmesini engeller. Bu mekanizmalar configuration-as-code ile yönetildiğinde değişiklikler review ve CI/CD sürecine dahil edilebilir.

Cloudflare R2 otomatik veri yükleme ve depolama yönetimi konusunda yakınımda danışmanlık veya eğitim nerede bulabilirim?

Cloudflare R2 entegrasyonunda yalnızca upload kodunu değil güvenlik, maliyet, backup ve event processing mimarisini birlikte değerlendirmek önemlidir. Kurumsal Cloudflare R2 entegrasyonu ve depolama otomasyonu hizmeti için mevcut sisteminizde file size dağılımı, upload trafik modeli, database metadata yapısı ve retention gereksinimleriyle başlanmalıdır. Diyarbakır Yazılım Topluluğu'nun teknik proje yaklaşımını https://www.diyarbakiryazilim.com.tr/projects adresinden inceleyebilirsiniz. Topluluk hakkında daha fazla bilgiye https://www.diyarbakiryazilim.com.tr/about üzerinden ulaşabilirsiniz. Doğru danışmanlık yaklaşımı tek bir hazır config vermek yerine sistemin mevcut yükünü ölçüp güvenli ve otomatik storage akışını bu ihtiyaçlara göre kurmalıdır.