DynamoDB Rehberi: Modern Uygulamalar için NoSQL Çözümü

1. DynamoDB Nedir? — noves.digital için Kısa Tanıtım

Amazon DynamoDB, AWS tarafından sunulan tam yönetilen, sunucusuz NoSQL veritabanı hizmetidir. Noves.digital ekibi olarak, İzmir merkezli yazılım projelerimizde yüksek performanslı ve ölçeklenebilir uygulamalar geliştirirken sıkça tercih ettiğimiz bu servis, milisaniyenin altında gecikme süreleriyle milyonlarca isteği karşılayabilir. Özellikle React, Next.js ve Node.js tabanlı modern web uygulamalarında, e-ticaret platformlarında ve IoT çözümlerinde DynamoDB'nin esnek veri modeli ve otomatik ölçeklenebilirlik özellikleri kritik avantajlar sunar. AWS altyapısının güvenliği ve global erişilebilirliği sayesinde, müşterilerimizin verilerini dünya genelinde düşük gecikme ile ulaştırabiliyoruz.

2. DynamoDB'nin Temel Özellikleri

2.1. Tam Yönetilen NoSQL Hizmeti

DynamoDB, altyapı yönetimi gerektirmeden çalışan tam yönetilen bir veritabanıdır. Sunucu kurulumu, yama yönetimi veya donanım ölçeklendirme gibi operasyonel yükleri AWS üzerine devreder. Noves.digital olarak projelerimizde bu özelliği kullanarak, müşterilerimizin iş mantığına odaklanmasını sağlıyoruz. Veritabanı yönetimi yerine, React ve Node.js ile geliştirilen uygulamanın kullanıcı deneyimini optimize etmeye odaklanabiliyoruz. Otomatik yedekleme, güvenlik güncellemeleri ve bakım pencereleri AWS tarafından yönetildiği için, ekiplerimiz CI/CD pipeline'ları ve yeni özellik geliştirme üzerine çalışabiliyor.

2.2. Yüksek Performans ve Düşük Gecikme

DynamoDB, tutarlı olarak tek haneli milisaniye gecikme süreleri sunar. SSD tabanlı depolama ve bellek içi önbellekleme (DAX) ile mikrosaniye seviyelerine inilebilir. Noves.digital'ın geliştirdiği e-ticaret çözümlerinde, kullanıcıların sepet işlemleri ve ürün aramaları anlık yanıt alır. IoT projelerimizde ise binlerce cihazdan gelen veri akışını gerçek zamanlı işleyebiliriz. Bu performans, kullanıcı memnuniyetini doğrudan etkiler; özellikle mobil uygulamalarda (Flutter ve React Native) hızlı veri erişimi, uygulamanın akıcılığını artırır. Performans SLA'ları AWS tarafından garanti edilir.

2.3. Otomatik Ölçeklenebilirlik ve Sunucusuz Kullanım

DynamoDB, trafik artışlarına otomatik yanıt verir. On-Demand kapasite modu ile istek sayısı arttıkça tablo otomatik ölçeklenir, azaldığında ise maliyet düşer. Noves.digital'ın geliştirdiği SaaS platformlarında, kullanıcı sayısı ani yükselişler gösterdiğinde (örneğin kampanya dönemlerinde) sistem kendini otomatik ayarlar. Sunucusuz mimari ile ödeme yaptığınız kadar kullanırsınız. Bu, startup ve ölçeklenmekte olan işletmeler için idealdir. Ayrıca, AWS Lambda ile entegrasyon sayesinde event-driven mimariler kurulabilir; veri değişiklikleri otomatik olarak downstream sistemlere iletilir.

3. Temel Kavramlar ve Terimler

3.1. Tablo, Öğe (Item) ve Öznitelik (Attribute)

DynamoDB'de veriler tablolarda saklanır. Her tablo öğelerden (item) oluşur ve her öğe bir veya daha fazla öznitelik (attribute) içerir. Öznitelikler, JSON benzeri bir yapıda key-value çiftleridir ve farklı öğeler farklı öznitelik setlerine sahip olabilir (schemaless). Noves.digital projelerinde, özellikle esnek veri yapılarına ihtiyaç duyulan e-ticaret sepetlerinde ve kullanıcı profillerinde bu esnekliği kullanırız. Bir ürün öğesinde renk, beden ve stok bilgileri; başka bir öğede ise sadece temel özellikler bulunabilir. Bu, ilişkisel veritabanlarındaki rigid şema kısıtlamalarından kurtarır.

{
  "userId": "usr_12345",
  "productId": "prd_67890",
  "quantity": 2,
  "addedAt": "2026-04-21T10:30:00Z",
  "metadata": {
    "color": "mavi",
    "size": "L"
  }
}

3.2. Partition Key ve Sort Key

Partition Key (PK), verinin hangi fiziksel bölümde (partition) saklanacağını belirler. Sort Key (SK) ise aynı partition içinde verilerin sıralanmasını sağlar. Birlikte Composite Primary Key oluştururlar. Noves.digital'ın e-ticaret projelerinde, PK = USER#<id> ve SK = ORDER#<tarih> yapısıyla bir kullanıcının siparişleri kronolojik sırada saklanır. Partition key'in dağılımı kritiktir; dengesiz dağılım "hot partition" sorununa yol açar. İyi tasarlanmış bir partition key, verinin 10 GB'lık partition limitini aşmadan, tutarlı performans sağlar.

3.3. Primary Key Türleri (Simple vs Composite)

Simple Primary Key sadece Partition Key'den oluşur ve her öğe benzersiz bir partition key'e sahip olmalıdır. Composite Primary Key ise Partition Key + Sort Key kombinasyonudur; aynı partition key'e sahip birden fazla öğe olabilir, ancak sort key birlikte benzersizliği sağlar. Noves.digital'ın IoT projelerinde cihaz ID'si partition key, timestamp sort key olarak kullanılır. Bu sayede bir cihazın tüm sensör verileri zaman sıralı erişilebilir. Simple key, tek bir öğeye hızlı erişim gerektiğinde (örneğin kullanıcı profili) idealdir. Composite key ise one-to-many ilişkiler için uygundur.

4. Veri Modelleme ve Tablo Tasarımı

4.1. Erişim Odaklı Tasarım Prensibi

DynamoDB'de veri modelleme, sorgu desenlerine göre yapılır. İlişkisel veritabanlarında olduğu gibi entity'lere göre değil, uygulamanın nasıl veri okuyacağına göre tasarlanır. Noves.digital ekibi olarak, proje başlangıcında tüm sorgu desenlerini belirleriz: "Kullanıcının son siparişleri neler?", "Belirli bir ürünün stok durumu nedir?". Her sorgu deseni için uygun primary key ve index yapısı kurulur. Bu yaklaşım, sonradan performans sorunları yaşamamak için kritiktir. Access patterns belirlendikten sonra, GSI ve LSI'ler bu desenlere göre optimize edilir.

4.2. Tek Tablo Tasarımı (Single Table Design)

Single Table Design, farklı entity türlerinin (kullanıcı, sipariş, ürün) tek bir DynamoDB tablosunda saklanmasıdır. Partition key ve sort key isimlendirme konvansiyonlarıyla entity'ler ayrılır: PK = USER#123, SK = PROFILE veya PK = USER#123, SK = ORDER#456. Noves.digital'ın mikroservis mimarilerinde bu deseni kullanarak, tek bir sorguyla ilişkili verileri birlikte çekebiliriz. Bu, JOIN operasyonları olmayan DynamoDB'de veri tutarlılığını ve sorgu verimliliğini artırır. Ancak dikkatli planlama gerektirir; tablo büyüdükçe yönetim karmaşıklaşabilir.

4.2.1. Örnek Veri Modeli: E-ticaret Sepeti

Noves.digital'ın geliştirdiği e-ticaret platformlarında aşağıdaki modeli kullanırız:

// Kullanıcı profili
{
  "PK": "USER#usr_123",
  "SK": "PROFILE",
  "name": "Ahmet Yılmaz",
  "email": "ahmet@example.com"
}

// Sepet öğesi
{
  "PK": "USER#usr_123",
  "SK": "CART#prd_456",
  "productName": "Kablosuz Kulaklık",
  "quantity": 1,
  "price": 899.99
}

// Sipariş
{
  "PK": "ORDER#ord_789",
  "SK": "METADATA",
  "userId": "usr_123",
  "total": 899.99,
  "status": "shipped",
  "createdAt": "2026-04-21"
}

Bu yapıyla Query(PK = "USER#usr_123") ile kullanıcının profili ve sepet öğeleri birlikte gelir.

4.2.2. Sorgu ve Tarama Maliyetlerini Azaltma

DynamoDB'de maliyet okunan/yazılan veri miktarına göre hesaplanır. Gereksiz öznitelikleri sorgulamaktan kaçınmak için ProjectionExpression kullanılır. Noves.digital projelerinde, sadece ihtiyaç duyulan alanları çekerek maliyeti optimize ederiz. Ayrıca, sık erişilen verileri aynı partition'da tutarak sorgu sayısını azaltırız. Pagination (Limit + LastEvaluatedKey) kullanarak büyük veri setlerini parçalar halinde işleriz. Filter Expression'lar sadece okunan veriyi filtreler; okuma maliyetini azaltmaz, bu nedenle primary key tasarımı kritiktir.

5. İndeksler ve Sorgulama

5.1. Global Secondary Index (GSI) Kullanımı

GSI'ler, tablonun primary key'inden farklı bir partition/sort key kombinasyonuyla sorgulama yapmanızı sağlar. Bir tabloda 20 GSI'e kadar oluşturulabilir. Noves.digital'ın e-ticaret projelerinde, ürünleri kategoriye göre listelemek için GSI kullanırız: GSI partition key = categoryId, sort key = price. Bu sayede "Elektronik kategorisindeki ürünleri fiyata göre sırala" sorgusu verimli çalışır. GSI'ler eventual consistency ile çalışır ve yazma maliyeti artırır; bu nedenle sadece gerçekten ihtiyaç duyulan desenler için oluşturulmalıdır.

// AWS SDK v3 ile GSI sorgusu
const command = new QueryCommand({
  TableName: "Products",
  IndexName: "CategoryPriceIndex",
  KeyConditionExpression: "categoryId = :cat",
  ExpressionAttributeValues: {
    ":cat": "electronics"
  },
  ScanIndexForward: false // Fiyata göre azalan sıralama
});

5.2. Local Secondary Index (LSI) ve Sınırlamaları

LSI'ler, aynı partition key ile farklı sort key'ler kullanarak sorgulama yapmanızı sağlar. Bir tabloda en fazla 5 LSI oluşturulabilir ve tablo oluşturulduktan sonra eklenemezler. Noves.digital projelerinde, aynı kullanıcının siparişlerini farklı kriterlere göre sıralamak için LSI kullanırız: Örneğin ana sort key createdAt, LSI sort key status#createdAt. LSI'ler strong consistency destekler ancak partition key değişmediğinden, cross-partition sorgular için GSI gerekir. LSI'lerin 10 GB'lık partition limiti vardır ve GSI'lere göre daha az esnektir.

6. Okuma/Yazma Kapasite Modları ve Maliyetler

6.1. Provisioned vs On-Demand Modları

Provisioned mode'da, saniye başına kaç okuma/yazma işlemi yapılacağı önceden belirlenir. Auto Scaling ile bu değerler otomatik ayarlanabilir. On-Demand mode'da ise kullanılan kadar ödenir ve kapasite planlaması gerekmez. Noves.digital'ın geliştirdiği MVP ve startup projelerinde genellikle On-Demand tercih ederiz; öngörülemeyen trafik desenlerinde maliyet kontrolü sağlar. Kurumsal projelerde ise provisioned + auto scaling kombinasyonu daha maliyet etkindir. On-Demand, provisioned'a göre yaklaşık 5-6 kat daha pahalıdır ancak operasyonel yükü azaltır.

6.2. Capacity Unit Hesaplama ve Optimizasyon

Bir Read Capacity Unit (RCU), 4 KB'lık verinin strongly consistent okunmasıdır. Eventually consistent okuma yarım RCU'dur. Write Capacity Unit (WCU), 1 KB'lık verinin yazılmasıdır. Transactional işlemler 2x kapasite tüketir. Noves.digital projelerinde, öznitelik boyutlarını optimize ederek maliyeti düşürürüz. Örneğin, büyük JSON objelerini ayrı tablolarda veya S3'te tutup referanslarını DynamoDB'de saklarız. 100 byte'lık bir öğe de 1 WCU, 1 KB'lık bir öğe de 1 WCU tüketir; bu nedenle batch yazma işlemlerini tercih ederiz.

6.2.1. Auto Scaling ile Maliyet Kontrolü

Auto Scaling, kapasiteyi belirlenen minimum-maksimum aralığında ayarlar. Noves.digital'ın projelerinde, kullanıcı aktivitesinin yoğun olduğu saatlerde (örneğin e-ticaret sitelerinde akşam saatleri) otomatik yükseliş, gece saatlerinde ise düşüş sağlarız. Target utilization %70 olarak ayarlanır; bu, ani trafik artışlarına karşı buffer bırakır. Ayrıca, AWS Application Auto Scaling ile Lambda concurrent execution'ları da senkronize edebiliriz. Maliyet alarmaları CloudWatch üzerinden kurulur ve bütçe aşımlarında bildirim gönderilir.

7. Tutarlılık Modelleri ve Transactionlar

7.1. Eventually Consistent vs Strongly Consistent Reads

Eventually consistent okumalar, yazma sonrası kısa bir süre (genellikle 1 saniyenin altında) eski veri döndürebilir. Strongly consistent okumalar ise her zaman en güncel veriyi garanti eder. Noves.digital'ın e-ticaret projelerinde, stok kontrolü ve ödeme işlemlerinde strongly consistent read kullanırız. Ürün listeleme ve öneri motorlarında ise eventually consistent yeterlidir ve maliyeti yarıya indirir. Strongly consistent, cross-region replikasyonunda ek gecikme oluşturabilir; bu nedenle global table'lar dikkatli değerlendirilmelidir.

7.2. ACID Transaction Desteği ve Kullanım Senaryoları

DynamoDB, 2018'den beri ACID transaction desteği sunar. TransactWriteItems ve TransactGetItems API'leri ile birden fazla öğe atomik olarak güncellenebilir. Noves.digital'ın finansal uygulamalarında, para transferi işlemlerinde kaynak ve hedef hesapların aynı anda güncellenmesini transaction ile garanti altına alırız. Bir transaction en fazla 25 öğe içerebilir ve toplam 4 MB veri boyutunu aşamaz. Transaction'lar 2x kapasite ünitesi tüketir. Mikroservis mimarilerinde, Saga pattern ile uzun süreli transaction'lar yönetilir.

const command = new TransactWriteItemsCommand({
  TransactItems: [
    {
      Update: {
        TableName: "Accounts",
        Key: { accountId: { S: "acc_123" } },
        UpdateExpression: "SET balance = balance - :amount",
        ConditionExpression: "balance >= :amount"
      }
    },
    {
      Update: {
        TableName: "Accounts",
        Key: { accountId: { S: "acc_456" } },
        UpdateExpression: "SET balance = balance + :amount"
      }
    }
  ]
});

8. Veri Güvenliği ve Yedekleme

8.1. IAM Roller, KMS ile Şifreleme

DynamoDB, AWS IAM ile fine-grained erişim kontrolü sağlar. Tablo düzeyinde, hatta öğe düzeyinde (fine-grained access control) yetkilendirme yapılabilir. Noves.digital projelerinde, her mikroservis için ayrı IAM rolleri tanımlar ve least privilege prensibini uygularız. Veri şifreleme için AWS KMS kullanılır; varsayılan olarak AWS managed key kullanılır ancak customer managed key (CMK) ile rotasyon ve erişim kontrolü sağlanabilir. Encryption at rest ve in transit (TLS) varsayılan olarak aktiftir. VPC Endpoint ile DynamoDB'ye public internet olmadan erişim sağlanabilir.

8.2. Point-in-Time Recovery (PITR) ve On-Demand Backups

PITR, son 35 gün içinde herhangi bir ana geri dönüş imkanı sunar. On-Demand Backups ise belirli bir anın snapshot'ını alır ve S3'te saklar. Noves.digital'ın kurumsal müşterilerinde, regülasyon gereksinimleri nedeniyle düzenli on-demand backup'lar alınır ve farklı AWS region'larına replike edilir. PITR, yanlışlıkla silinen verilerin veya hatalı güncellemelerin geri alınması için idealdir. Backup'lar tablo performansını etkilemez ve maliyeti, backup boyutuna göre hesaplanır. Cross-region backup copy ile disaster recovery stratejileri güçlendirilir.

9. DynamoDB Streams ve Event Tabanlı Entegrasyon

9.1. Lambda ile Gerçek Zamanlı İşlem Akışları

DynamoDB Streams, tablodaki her değişikliği (insert, update, delete) sıralı ve tam olarak kaydeder. AWS Lambda ile entegre edilerek, veri değişikliklerine anında tepki verilebilir. Noves.digital'ın e-ticaret projelerinde, sipariş durumu değiştiğinde otomatik e-posta gönderimi, stok güncellemesi ve analitik event'leri bu şekilde yönetiriz. Stream'ler 24 saat saklanır ve paralel Lambda consumer'lar ile işlenebilir. Event filtering sayesinde, sadece belirli değişiklik türleri Lambda'yı tetikler; bu maliyeti optimize eder.

# Lambda handler örneği
import json

def lambda_handler(event, context):
    for record in event['Records']:
        if record['eventName'] == 'INSERT':
            new_image = record['dynamodb']['NewImage']
            order_id = new_image['orderId']['S']
            # E-posta gönderimi veya analitik işlemi
            print(f"Yeni sipariş alındı: {order_id}")
    return {'statusCode': 200}

9.2. Change Data Capture (CDC) Senaryoları

CDC, veritabanı değişikliklerinin downstream sistemlere (Elasticsearch, Redshift, S3) aktarılmasıdır. DynamoDB Streams + Lambda kombinasyonu ile CDC pipeline'ları kurulur. Noves.digital'ın analitik projelerinde, DynamoDB'deki işlem verileri anlık olarak S3'e ve ardından AWS Glue ile Redshift'e aktarılır. Bu, operasyonel veritabanını analitik yükten korur. Ayrıca, Elasticsearch'e senkronizasyon ile full-text search yetenekleri eklenir. CDC, mikroservis mimarilerinde event sourcing pattern'in temelini oluşturur ve servisler arasında loose coupling sağlar.

10. Global Tables ve Çok Bölgeli Replikasyon

10.1. Çok Bölge Okuma/Yazma Senaryoları

DynamoDB Global Tables, aynı tablonun birden fazla AWS region'ında aktif-aktif replikasyonunu sağlar. Her region'dan hem okuma hem yazma yapılabilir. Noves.digital'ın global e-ticaret müşterilerinde, Avrupa, Amerika ve Asya'daki kullanıcılara yerel gecikme süreleriyle hizmet vermek için kullanırız. Kullanıcı en yakın region'a yazar ve veri diğer region'lara milisaniyeler içinde replike olur. Bu, cross-region latency'yi ortadan kaldırır ve uygulama kullanılabilirliğini artırır. Özellikle mobil uygulamalarda (Flutter/React Native) kullanıcı deneyimi dramatik olarak iyileşir.

10.2. Gecikme, Çakışma Çözümü ve Maliyet Etkisi

Global Tables'da yazma işlemleri son yazan kazanır (last writer wins) prensibiyle çakışmalar çözülür. Noves.digital projelerinde, çakışma riskini minimize etmek için iş mantığı seviyesinde idempotency token'ları kullanırız. Replikasyon maliyeti, yazılan verinin her region'a kopyalanmasından kaynaklanır; bu nedenle yazma yoğunluklu tablolar dikkatli değerlendirilmelidir. Ayrıca, Global Tables On-Demand mode'da çalışır ve provisioned mode desteklemez. Cross-region veri transfer ücretleri de maliyeti etkiler. CloudWatch metric'leri ile replikasyon lag izlenir.

11. İzleme, Performans ve Optimizasyon Araçları

11.1. CloudWatch Metrikleri ve Alarm Kuralları

DynamoDB, CloudWatch üzerinden ConsumedReadCapacityUnits, ConsumedWriteCapacityUnits, ThrottledRequests, UserErrors, SystemErrors gibi metrikler sunar. Noves.digital'ın projelerinde, throttle olayları için alarm kurar ve anında Auto Scaling ayarlarını veya kapasite modunu değiştiririz. Ayrıca, SuccessfulRequestLatency metriği ile beklenmedik gecikme artışlarını tespit ederiz. Contributor Insights ile hangi partition key'lerin en çok trafik aldığı görülebilir; bu, hot partition analizi için kritiktir. CloudWatch Logs ile DynamoDB operations log'ları merkezi olarak izlenir.

11.2. Partition Anahtarının (Partition Key) İzlenmesi

Hot partition, tek bir partition key'in çok fazla trafik almasıdır ve throttle'lara yol açar. Noves.digital projelerinde, partition key seçiminde yüksek kardinalite (çok sayıda benzersiz değer) hedefleriz. Örneğin, userId yerine userId#date kombinasyonu kullanılabilir. CloudWatch Contributor Insights ile en çok erişilen partition key'ler izlenir. Adaptive capacity, hot partition'ları otomatik olarak izole eder ancak en iyi çözüm doğru partition key tasarımıdır. Partition key prefix'leri ile veri dağılımı optimize edilebilir.

12. Yedekleme, Göç ve Entegrasyon Stratejileri

12.1. RDS/Relational'dan DynamoDB'ye Geçiş

İlişkisel veritabanından DynamoDB'ye geçiş, veri modelinin yeniden tasarlanmasını gerektirir. Noves.digital'ın modernizasyon projelerinde, önce mevcut sorgu desenlerini analiz ederiz. AWS DMS (Database Migration Service) ile veri aktarımı yapılır ancak schema dönüşümü manueldir. JOIN'ler denormalize edilir, one-to-many ilişkiler composite key'lerle modellenir. Geçiş sırasında dual-write pattern kullanılır; uygulama hem eski hem yeni veritabanına yazar, okumalar ise A/B test ile yönlendirilir. Veri tutarlılığı için CDC ve reconciliation job'ları çalıştırılır.

12.2. ETL, Glue ve Kinesis ile Veri Akışı

DynamoDB verileri, AWS Glue ile S3'e ve ardından analitik araçlara (Athena, Redshift, QuickSight) aktarılır. Noves.digital'ın veri analitiği projelerinde, Glue Crawler ile DynamoDB schema'sı otomatik keşfedilir ve ETL job'ları ile veri transformasyonu yapılır. Kinesis Data Streams, gerçek zamanlı veri akışları için kullanılır; IoT cihaz verileri Kinesis üzerinden DynamoDB'ye ve analitik pipeline'lara paralel olarak iletilir. Bu mimari, operasyonel ve analitik iş yüklerini ayırarak DynamoDB performansını korur.

13. En İyi Uygulamalar ve Yaygın Hatalar

13.1. Sorgu Odaklı Tasarım ve Hot Partition Önleme

En yaygın hata, ilişkisel düşünceyle DynamoDB tasarlamaktır. Noves.digital ekibi olarak, her zaman erişim desenlerini önce belirleriz. Hot partition önlemek için: (1) Yüksek kardinaliteli partition key'ler seçin, (2) Write sharding ile prefix ekleyin (örn. deviceId#2026-04-21), (3) GSI'lerde partition key dağılımını kontrol edin. Ayrıca, scan operasyonlarından kaçının; scan tüm tabloyu tarar ve maliyetli/pahalıdır. Pagination kullanın ve paralel scan'ları sadece büyük veri setlerinde düşünün.

13.2. Maliyet İzleme ve Test Yükleri

DynamoDB maliyetleri öngörülemeyen şekilde artabilir. Noves.digital projelerinde, AWS Cost Explorer ile günlük/haftalık maliyet takibi yaparız. Load testing sırasında, gerçekçi veri boyutları ve erişim desenleri kullanırız. Artillery veya k6 ile simülasyon yaparız. On-Demand mode'da ani trafik artışlarına karşı bütçe alarmaları kurarız. Provisioned mode'da ise reserved capacity satın alarak uzun vadeli maliyet tasarrufu sağlarız. Maliyet optimizasyonu, projenin her aşamasında göz önünde bulundurulmalıdır.

14. Kullanım Senaryoları ve Örnek Mimariler

14.1. E-ticaret, Oyun, IoT ve Analitik Senaryoları

DynamoDB, farklı sektörlerde çok yönlü çözümler sunar. Noves.digital'ın e-ticaret projelerinde sepet, sipariş ve stok yönetimi; oyun projelerinde lider tablosu ve oyuncu durumu; IoT projelerinde cihaz telemetrisi ve alarm yönetimi için kullanırız. Analitik senaryolarda, gerçek zamanlı dashboard'lar ve clickstream analizi için DynamoDB + Lambda + Elasticsearch stack'ini tercih ederiz. Her senaryoda, veri modeli o senaryonun erişim desenlerine özel tasarlanır. Örneğin IoT'te time-series pattern, oyunlarda leaderboard pattern kullanılır.

14.2. Serverless Mikroservis Mimarilerinde DynamoDB

Noves.digital'ın serverless mikroservis mimarilerinde, DynamoDB merkezi veri deposu olarak görev alır. API Gateway + Lambda + DynamoDB üçlemesi, tam sunucusuz bir backend oluşturur. Her mikroservis kendi DynamoDB tablosunu (veya single table design'da kendi prefix'ini) kullanır. EventBridge ve SNS ile servisler arası asenkron iletişim sağlanır. Step Functions ile saga pattern ve uzun süreli iş akışları yönetilir. Bu mimari, otomatik ölçeklenme, düşük operasyonel yük ve kullanım başına maliyet avantajları sunar.

15. SDK'lar, CLI ve Operasyonel Komutlar

15.1. AWS SDK (JavaScript, Python, Java) Örnekleri

Noves.digital projelerinde Node.js (AWS SDK v3) ve Python (boto3) en sık kullanılan SDK'lardır. SDK v3, modüler yapısıyla bundle boyutunu minimize eder. TypeScript ile tip güvenliği sağlanır. Aşağıda Node.js örneği verilmiştir:

import { DynamoDBClient } from "@aws-sdk/client-dynamodb";
import { DynamoDBDocumentClient, PutCommand, GetCommand } from "@aws-sdk/lib-dynamodb";

const client = new DynamoDBClient({ region: "eu-central-1" });
const docClient = DynamoDBDocumentClient.from(client);

// Öğe ekleme
await docClient.send(new PutCommand({
  TableName: "Users",
  Item: { userId: "usr_123", name: "Ahmet", email: "ahmet@noves.digital" }
}));

// Öğe okuma
const result = await docClient.send(new GetCommand({
  TableName: "Users",
  Key: { userId: "usr_123" }
}));

Python'da boto3 kullanımı benzer şekildedir. Java için AWS SDK for Java v2 tercih edilir.

15.2. Sık Kullanılan CLI Komutları ve İpuçları

AWS CLI ile hızlı operasyonlar yapılabilir. Noves.digital ekibi olarak, geliştirme ve debug süreçlerinde sıkça kullanırız:

# Tablo listeleme
aws dynamodb list-tables --region eu-central-1

# Öğe sorgulama
aws dynamodb get-item --table-name Users --key '{"userId":{"S":"usr_123"}}'

# Tablo bilgisi
aws dynamodb describe-table --table-name Users

# Scan (küçük tablolarda)
aws dynamodb scan --table-name Users --limit 10

# Öğe silme
aws dynamodb delete-item --table-name Users --key '{"userId":{"S":"usr_123"}}'

--endpoint-url http://localhost:8000 ile local DynamoDB'ye bağlanabilir. --no-paginate ile tüm sonuçları tek seferde alabilirsiniz.

16. Fiyatlandırma Özeti ve Maliyet Tahmini

16.1. Örnek Maliyet Hesapları (On-Demand vs Provisioned)

Noves.digital'ın tipik bir e-ticaret projesini örnek alalım: Günde 1 milyon okuma (4 KB), 500 bin yazma (1 KB). On-Demand: 1M okuma = $0.25, 500K yazma = $1.25; günlük $1.50, aylık ~$45. Provisioned (Auto Scaling %70 target): RCU 150, WCU 200; aylık ~$30. Reserved capacity ile %53 tasarruf sağlanabilir. Transaction'lar 2x maliyetlidir. GSI'ler ana tablo ile aynı fiyatlandırmaya sahiptir. Global Tables'da her region için ayrı yazma maliyeti ödenir. PITR ve backup'lar ayrıca ücretlendirilir.

16.2. Tasarruf İçin Pratik Öneriler

Noves.digital olarak uyguladığımız tasarruf stratejileri: (1) Doğru kapasite modunu seçin; öngörülemeyen trafikte On-Demand, stabil trafikte Provisioned. (2) Öznitelik boyutlarını optimize edin; gereksiz verileri S3'e taşıyın. (3) Batch işlemleri kullanın (BatchWriteItem, BatchGetItem). (4) Eventually consistent okumaları tercih edin. (5) GSI sayısını minimize edin. (6) TTL (Time To Live) ile eski verileri otomatik silin. (7) Reserved capacity satın alın. (8) AWS Cost Anomaly Detection ile beklenmedik maliyet artışlarını yakalayın.