Init Amortismanına Göre Kod Mimarisi: Lambda'da Yalın, Ağırlık Ancak Hak Edilince

Problem#

1. Bölüm Lambda sorusunun topoloji yarısını yanıtladı: single responsibility bir kod ilkesidir, kaç fonksiyon deploy edileceği ise ayrı bir topoloji kararıdır. Diğer yarı, belirli bir runtime’ın içine ne kadar kod mimarisi girmesi gerektiğidir: ne kadar OOP, dependency injection ve framework ağırlığı. Yanıt 1. Bölüm’ün “istisnayı hak et” biçimini yansıtır: varsayılan olarak yalın fonksiyonel handler kullan, sonra her runtime’ın init-amortismanı izin verdikçe daha ağır yapıyı hak et. Kararı belirleyen değişken, tek bir initialization’ın kaç invocation’a hizmet ettiğidir.

Bu ayrım önemlidir çünkü ekipler mimariyi alışkanlığa göre seçer. Tam bir NestJS dependency-injection grafiği single-purpose bir fonksiyon olarak deploy edilir; orada neredeyse her cold start’ta decorator taraması yaparak yaklaşık tek bir amaca hizmet eder. Tersi de olur: yalın bir fonksiyonel handler, hiçbir connection pool’u tekrar kullanmayan uzun ömürlü bir Fargate servisine yayılır ve runtime’ın bedava sunduğu amortismanı çöpe atar. Her iki uyumsuzluk da bir paradigmayı, neyin değiştiğini sormadan bir runtime sınırından öbürüne taşımaktan doğar.

Burada TypeScript ve Node ana yoldur; Java ve Spring, kanonik ağır dependency-injection örneği olarak öne çıkar ve o örnek ters köşe bir nüans taşır.

Init-Amortisman Modeli#

Tüm kararı tek bir sayı yönetir: initialization başına hizmet edilen invocation sayısı. Mimarinin ağırlığı bu oranı izlemeli, çünkü framework başlangıcının her baytı initialization başına bir kez ödenir ve sonrasında bedava tekrar kullanılır. Tekrar kullanım ne kadar çoksa, ağırlık o kadar ucuzdur.

Üç runtime bu oranın üç noktasında durur.

• FaaS single-purpose: bir cold environment init’i bir kez çalıştırır, sonra atıl kalıp temizlenene kadar yaklaşık tek bir mantıksal amaca hizmet eder. AWS, Lambda’nın her eşzamanlı istek için ayrı bir execution environment ayırdığını ve yeni bir tanesini başlatması gerektiğinde cold start yaşandığını belgeler. Yani init maliyeti, yapılan işe kıyasla orantısız sıklıkta ödenir. Burada init ağırlığı baskın değişkendir.
• Lambdalith (single-domain): tek bir warm environment init’i bir kez çalıştırır, sonra bounded context’teki her route’a hizmet eder. Aynı router yapısı ve dependency-injection grafiği birçok heterojen isteğe amortize edilir. Orta yapı kazanmaya başlar.
• Fargate: bir task bir kez başlar ve container’ın tüm ömrü boyunca çalışır, böylece init bir kez ödenir ve her isteğe amortize olur; yanı sıra uzun ömürlü bir sürecin tuttuğu kalıcı pool’lar ve cache’ler de. Ağır dependency injection ve hexagonal katmanlama burada neredeyse bedavadır. Bu basamak herhangi bir uzun ömürlü runtime’ı temsil eder.

Bu listede aşağı indikçe amortisman oranı yükselir ve göze alınabilir mimari ağırlık da onunla yükselir: kararın omurgası budur. Kararın çoğu bu listenin tepesinde, Lambda tarafında yaşar; single-purpose ile Lambdalith arasındaki seçim ağırlığın gerçekten bir bedeli olduğu yerdir, Fargate’e gelindiğindeyse bu bedel neredeyse bedavadır.

Üç Yaşam Döngüsü, Tek Kısıt#

Oran, her runtime’ın nasıl doğup öldüğünden gelir; bu yüzden yaşam döngülerini bir kez söylemeye değer.

FaaS önce INIT fazını çalıştırır (indirme, ortam kurulumu, modül init), sonra environment’ı dondurur, sonra sonraki invocation’lar için belki warm olarak tekrar kullanır, sonra eninde sonunda temizler. Ölçekleme granülaritesi istek başınadır. Tekrar kullanım garantili olmayıp duruma bağlı olduğundan, bir connection pool’unun veya bellek içi cache’in invocation’lar arasında ayakta kaldığını varsayamazsınız. Hem cold hem warm yola göre tasarlamak ve bağlantı yönetimini RDS Proxy gibi bir proxy’ye taşımak, bunun ardından gelen disiplindir.

Lambdalith aynı Lambda yaşam döngüsünü kullanır, ama handler bir router’dır. Tek bir init router’ı ve paylaşılan servisleri kurar ve bir warm environment o tek yapıdan N route handler’a hizmet eder. Amortisman gerçektir, ama o tek fonksiyonun kendi trafiğiyle ne sıklıkta warm kaldığıyla sınırlıdır.

Fargate uzun ömürlü bir süreçten isteklere hizmet eder. Task ekleyerek ölçeklersiniz ve istek başına cold start yoktur. Init boot’ta bir kez ödenir ve task’in tüm ömrü boyunca tekrar kullanılır; bu da bir task içindeki uzun ömürlü stateful bir nesneyi bir kez kurup tutmayı güvenli kılar. Buradaki tek önemli mimari sonuç, herhangi bir uzun ömürlü runtime için de geçerlidir: pahalı şeyler boot’ta bir kez kurulur ve sonrasında gelen her istekte tekrar kullanılır.

Geniş Compute Merdiveni#

Bu üç nokta daha uzun bir merdivenin üstünde durur ve merdivenin tamamını görmek iki hatayı önler: Fargate’i Lambda’dan sonraki ilk durak sanmak ve single-purpose ile Lambdalith’i bir ölçekleme tercihi sanmak. Single-purpose ve Lambdalith aynı compute tier’dır (Lambda), istek başına ve sıfıra ölçeklenir; aralarındaki fark kod topolojisidir.

Container’a atlamadan önce Lambda’nın çoğu ekibin yeterince kullanmadığı bir genişleme payı vardır. Tek bir fonksiyon 15 dakikaya kadar çalışabilir, 10.240 MB’a kadar memory ve 10.240 MB’a kadar ephemeral storage kullanabilir ve container image olarak paketlenebilir. Bir fonksiyon büyük hissettirir hissettirmez container’a uzanmak yaygın bir uyumsuzluktur. Daha şişman bir Lambda ya da bir Lambdalith çoğu zaman hâlâ yeter ve scale-to-zero’yu korur. (AWS App Runner eskiden buradaki yönetilen-container boşluğunu doldururdu, ama yeni müşterilere kapalıdır, dolayısıyla yeni projeler için bir yol değildir.)

Lambdalith’ten Fargate’e geçiş bir uçurum değil bir yokuştur, çünkü iki kaldıraç bir Lambda’yı Lambda’dan çıkmadan Fargate’in şekline taşır. Birincisi paketleme. AWS Lambda Web Adapter ile standart bir Express, Fastify ya da Spring web sunucusunu, Fargate’e deploy edeceğiniz aynı container image olarak, Lambda üzerinde çalıştırırsınız. Artifact yakınsar, çalışma modeli ise istek başına kalır ve sıfıra iner. İkincisi warmth. Provisioned concurrency başlatılmış environment’ları hazır tutar ve her iki paketlemeyle de, birinci kaldıraçtaki container image dahil, çalışır. Boştayken bile o warm tabanı faturalandırır, tıpkı Fargate’in bir task tutarak yaptığı takas gibi. SnapStart aynısını Java, Python ve .NET’te yapar, ama yalnızca managed runtime’larda zip paketleri için, container image’ları için değil; yani container-image yolu yerine Web Adapter layer’ı ile eşleşir. Paketleme ve warmth ikisi de halledildiğinde, Fargate ile aradaki fark faturalama granülaritesine, arka plan işine ve Lambda’nın 15 dakikalık tavanına iner. Bunlara gerçekten ihtiyaç duyduğunuzda Fargate’e geçersiniz.

Fargate’in altı, çoğu Lambda-tarafı ekibin hiç ihtiyaç duymadığı bölgedir: GPU, bin-packing ya da daemon iş yükleri için kapasiteyi yönetmeniz gerektiğinde ECS ya da EKS on EC2, sonra ham EC2 ve bare metal. Her adım scale-to-zero’yu kontrolle takas eder, ama hiçbiri mimari soruyu değiştirmez, yalnızca etrafındaki operasyonu.

Mimari kararı içinse merdiven üç banda iner. Ephemeral-per-request iş (single-purpose Lambda) yalın ister. Router-amortized iş (Lambdalith) orta ister. Bir kez kurulup ömrü boyunca yeniden kullanılan her uzun ömürlü süreç (Fargate, ECS ya da EKS on EC2 ya da düz bir EC2 servisi) tam ağırlığın karşılanabildiği aynı banda girer, çünkü hepsi init’i süreç ömrüne amortize eder. Provisioned concurrency ya da SnapStart’lı bir Lambda da aynı banda girer, çünkü init’i amortize eden şey, runtime ne olursa olsun, warmth’tir. O alt basamaklar operasyon, maliyet ve ölçekleme granülaritesinde farklılaşır; taşıyabildikleri mimari ağırlık aynıdır. Mimariyi gerçekten değiştiren yalnızca üç nokta vardır: single-purpose Lambda, Lambdalith ve Fargate’in temsil ettiği uzun ömürlü bant.

Runtime Başına Paradigma: Varsayılan Yalın#

Paradigma ekseni (fonksiyonel ile OOP, framework’süz ile ağır framework) doğrudan oranla eşleşir.

FaaS single-purpose’ta yalın fonksiyonel handler#

Burada en aza indirilecek değişken init ağırlığıdır: single-purpose bir fonksiyon, cold environment başına yaklaşık tek bir amaca hizmet eder. Fonksiyonel bir çekirdek (saf fonksiyonlar artı ince bir imperatif kabuk) tek bir handler’a doğal olarak oturur. Küçük ölçekte OOP sorun değil: bir value object, küçük bir sınıf, odaklı bir servis. Anti-pattern, tam bir dependency-injection container’ını ve decorator tarayan bir framework’ü, tek bir iş yapmak için var olan bir fonksiyonun içine sürüklemektir.

// src/orders/create.ts - lean functional handler, minimal deps, lazy init
import type { APIGatewayProxyHandlerV2 } from "aws-lambda";
import { DynamoDBClient } from "@aws-sdk/client-dynamodb";
import { DynamoDBDocumentClient, PutCommand } from "@aws-sdk/lib-dynamodb";

// Built once at module load, reused across warm invocations.
const ddb = DynamoDBDocumentClient.from(new DynamoDBClient({}));
const TABLE = process.env.ORDERS_TABLE!;

// Pure core: no AWS, no I/O, trivially testable.
function toOrder(input: { sku: string; qty: number }) {
  return { id: crypto.randomUUID(), ...input, createdAt: Date.now() };
}

export const handler: APIGatewayProxyHandlerV2 = async (event) => {
  const input = JSON.parse(event.body ?? "{}");
  const order = toOrder(input);
  await ddb.send(new PutCommand({ TableName: TABLE, Item: order }));
  return { statusCode: 201, body: JSON.stringify(order) };
};

Saf fonksiyon domain kuralını tutar; handler ince imperatif kabuktur. Cold yolda hiçbir container grafik kurmaz; modül yüklenirken yalnızca bir client kurulur ve warm invocation’lar onu tekrar kullanır.

Lambdalith’te orta yapı#

Bir Lambdalith router’ını ve servislerini bir kez kurar ve her route’a amortize eder; bir servis katmanını ve hafif dependency injection’ı göze alabilmesinin nedeni budur. Tatlı nokta bir karışımdır: küçük bir OOP servis katmanının önünde fonksiyonel route handler’lar, cold start’ta çalışan ve tüm route’larca paylaşılan tek bir composition root ile bağlanır.

// src/composition.ts - one composition root, built once, shared by every route
import { DynamoDBClient } from "@aws-sdk/client-dynamodb";
import { DynamoDBDocumentClient } from "@aws-sdk/lib-dynamodb";

export class OrderService {
  constructor(private readonly ddb: DynamoDBDocumentClient, private readonly table: string) {}
  // ... domain methods reused across routes
}

// Light, hand-wired DI: no decorator scanning, built at module load.
const ddb = DynamoDBDocumentClient.from(new DynamoDBClient({}));
export const orders = new OrderService(ddb, process.env.ORDERS_TABLE!);

// src/handler.ts - router amortizes one init across many routes
import { Hono } from "hono";
import { handle } from "hono/aws-lambda";
import { orders } from "./composition";

const app = new Hono();
app.get("/orders/:id", (c) => c.json(/* orders.get(...) */ { id: c.req.param("id") }));
app.post("/orders", async (c) => c.json(/* orders.create(...) */ await c.req.json(), 201));

export const handler = handle(app); // one Lambda, every route reuses `orders`

Hono buradaki düşük-init router’dır, ama aynı biçim 1. Bölüm’ün ele aldığı AWS Lambda Web Adapter üzerinden Fastify veya Express için de geçerlidir. NestJS bir Lambdalith üzerinde aynı amortisman nedeniyle uygulanabilirdir: dependency-injection container’ı cold start’ta bir kez kurulur ve warm environment’ta her route’a tekrar kullanılır. Maliyet cold yola düşer, bu yüzden grafik ne kadar ağırsa, aşağıdaki cold-start kaldıracı o kadar önemlidir.

Fargate’te tam OOP, DI, hexagonal#

Zengin domain modelleri, eager singleton’lar ve kalıcı pool’lar kendini amorti eder; çünkü Fargate task’i her şeyi bir kez kurar ve task’in ömrü boyunca tekrar kullanır. İstek başına cold start olmadığından ağırlık amortize edilmiş anlamda neredeyse bedavadır; bu da burayı tam bir Spring ya da NestJS grafiğinin doğal evi yapar. Tek hata modu, uzun ömürlü bir task içinde istek başına yeniden başlatmaktır ki bu da runtime’ın verdiği avantajı çöpe atar.

Bu runtime’lardan herhangi birinde fonksiyonel TypeScript desenleri için Effect benimseme rehberine bakın; özellikle Fargate üretim operasyonları için Fargate üretim dersleri yazısına bakın. O konular onlara sahip olan kardeş yazılara aittir.

Tek Çekirdek, Ayarlanan Kenarlar#

Runtime başına ayarlamayı pahalı yerine ucuz kılan yeniden çerçeveleme şudur: clean architecture çekirdeği taşınır, yalnızca kenarlar değişir. Bir ports-and-adapters veya clean-architecture domain çekirdeği tanım gereği delivery mekanizmasından bağımsızdır, bu yüzden aynı domain kodu FaaS’tan Lambdalith’e ve Fargate’e değişmeden taşınır. Runtime başına ayarladığınız şey composition root ve adapter kenarıdır: çekirdeğin etrafına ne kadar framework ve dependency injection sardığınız ve bunu ne kadar eager yaptığınız. Çekirdek hangi runtime’da çalıştığını bilmez, bilmemeli de.

Pratikte kenarlar tam olarak tek bir şeyde ayrışır: composition root’ta, yukarıdaki diyagramda görüldüğü gibi.

İşte bu yüzden “runtime değiştirirken domain mantığımı yeniden mi yazmalıyım?” sorusunun net bir yanıtı var: hayır. Domain çekirdeği handler’a ya da framework’e bağlıysa, bir runtime değişimi yeniden yazmaya zorlar ve o bağımlılık asıl tuzaktır. Bağımsız bir çekirdek, runtime değişiminin etkisini composition root ile sınırlı tutar.

SnapStart ve Provisioned Concurrency#

Varsayılan yalındır ve aşma durumu “FaaS’ta ağır bir kenarı korumak zorundayım”dır. Bu olur ve AWS bunun için iki kaldıraç sunar. Hangisini kullanabileceğiniz, çoğu ekibi şaşırtan bir biçimde runtime dilinize bağlıdır.

Provisioned concurrency execution environment’ları önceden başlatır, böylece init, dependency-injection grafiği kurulumu dahil, trafik gelmeden ödenir. AWS, provisioned-concurrency environment’larını çift haneli milisaniyede yanıt vermeye hazır olarak tanımlar. Her zaman açık bir ücret taşır, çünkü bir instance hiçbir isteğe hizmet etmese bile Lambda o initialization’ı faturalandırır. Node ve TypeScript ana yolu için, mevcut tek cold-start kaldıracı budur.

SnapStart bir versiyon yayınladığınızda başlatılmış execution environment’ın bir Firecracker microVM snapshot’ını alır, sonra environment’ları sıfırdan başlatmak yerine o önbelleğe alınmış snapshot’tan geri yükler. AWS bunu tam olarak bu probleme yanıt olarak çerçeveler: “modül dependency’leri veya framework’leri yükleme gibi” tek seferlik initialization kodundan gelen gecikme değişkenliği ki bunun “bazen birkaç saniye sürebileceğini” belirtir. Bu, AWS tarafından adı konmuş ağır dependency-injection cold start’ıdır. Üç kısıt, nerede işe yaradığını sınırlar:

• Runtime desteği dardır. SnapStart yalnızca Java 11+, Python 3.12+ ve .NET 8+ destekler. Node.js (nodejs24.x) ve Ruby desteklenmez; OS-only runtime’lar ya da container image’ları da desteklenmez. Yani TypeScript kitlesi SnapStart’ı hiç kullanamaz; provisioned concurrency Node kaldıracıdır.
• Aynı fonksiyon versiyonunda provisioned concurrency ile karşılıklı dışlayıcıdır. Birini seçersiniz.
• Fiyatlandırma runtime’a göre değişir. SnapStart, Java managed runtime’larında ek ücret taşımaz. Python ve .NET’te, yayınlanan versiyon başına bir önbellekleme ücreti artı bir environment her geri yüklendiğinde bir geri yükleme ücreti ödersiniz. Eski “SnapStart bedava” genellemesi yalnızca Java’ya özgüdür; onu diğer runtime’lara taşımayın.

Bir de doğruluk kısıtı var. Tek bir snapshot birçok environment’a tekrar kullanıldığından, environment başına benzersiz olması gereken her şey (tohumlanmış rastgelelik, önceden açılmış bağlantılar) bir runtime hook’u gerektirir; AWS bunu açıkça belirtir: “uygulamalarınız durum benzersizliğine bağlıysa, fonksiyon kodunuzu değerlendirmelisiniz.” Ve SnapStart en az tam olarak amortisman omurgasının öngördüğü yerde yardımcı olur: AWS, seyrek çağrılan fonksiyonların aynı iyileşmeyi görmeyebileceğini belirtir.

Şimdi ters köşe. En sık “Lambda için fazla ağır” diye dışlanan framework, JVM üzerindeki Spring, SnapStart’ta bedava bir init kaldıracına sahip. Serverless dostu denen daha hafif Node yolunda yalnızca ücretli kaldıraç, provisioned concurrency var. Yani “JVM serverless için fazla ağır” kısmen geçersiz ve “Node her zaman serverless dostu seçimdir” cold-start’a duyarlı, ağır-init yollar için kısmen yanlış. Asimetri doğrudan AWS dokümanlarından gelir. Tam cold-start araç seti (paket init, snapshot ayarı, bu kaldıraçların ardındaki yaşam döngüsü mekaniği) için AWS Lambda cold start optimizasyonu yazısına bakın.

Adı konmaya değer bir tuzak daha, çünkü en yaygın yanlış çerçeveleme bu: “framework’ler Lambda’da yavaştır”ı hikayenin tamamı sanmak. Bu bir init-amortisman problemidir. Bir dependency-injection grafiği bir kez kurulup warm olduğunda, p50 ya da p99 istek gecikmesini vergilendirmez; ağırlık neredeyse tamamen init’te yaşar. Çözüm, framework’ü hareket ettirmediği steady-state sayıları için suçlamak yerine, init süresini (Lambda’nın CloudWatch ve X-Ray’de görünen Init Duration’ı) ve tekrar kullanım oranını, invoke gecikmesinden ayrı ölçmektir.

Sonuç#

Sınır net: tam framework ve dependency-injection ağırlığı, amortisman onu ödediğinde doğrudur; bu da varsayılan olarak uzun ömürlü bir servis (Fargate ya da ECS/EKS on EC2), ya da SnapStart (Java, Python ya da .NET) veya provisioned concurrency (Node kaldıracı) arkasına koyduğunuz bir Lambda demektir.

Kaynaklar#

• Understanding the Lambda execution environment lifecycle (yeni sekmede açılır) - INIT/freeze/restore fazları, cold ve warm karşılaştırması ve istek başına environment ayırma üzerine AWS dokümantasyonu: amortisman modelinin üzerine kurulduğu yaşam döngüsü.
• Improving startup performance with Lambda SnapStart (yeni sekmede açılır) - Firecracker microVM snapshot mekanizması, desteklenen runtime’lar (Java 11+, Python 3.12+, .NET 8+; Node ve Ruby değil), framework yükleme amaç ifadesi, provisioned concurrency ile karşılıklı dışlama, fiyatlandırma ve durum-benzersizliği uyarısı üzerine AWS dokümantasyonu.
• AWS Fargate on Amazon ECS (“Architect for AWS Fargate”) (yeni sekmede açılır) - Uzun ömürlü task modeli, task başına izolasyon, task düzeyinde ölçekleme ve istek başına cold start’ın yokluğu üzerine AWS dokümantasyonu.
• Lambda quotas (yeni sekmede açılır) - Lambda’nın katı limitleri üzerine AWS dokümantasyonu: invocation başına 15 dakikaya kadar, 10.240 MB’a kadar memory ve 512 ile 10.240 MB arası ephemeral storage; container’a uzanmadan önce tüketilecek genişleme payı.
• AWS App Runner availability change (yeni sekmede açılır) - App Runner’ın yeni müşterilere kapalı olduğuna dair AWS duyurusu; Lambda ile Fargate arasındaki yönetilen-container basamağının yeni projeler için neden bir yol olmadığı.
• Configuring provisioned concurrency (yeni sekmede açılır) - Önceden başlatılmış environment’lar, çift haneli milisaniye hazırlığı ve bir instance hiçbir isteğe hizmet etmese bile initialization’ın faturalandırılması üzerine AWS dokümantasyonu: Node yolunun cold-start kaldıracı.
• Well-Architected Serverless Applications Lens: design principles (yeni sekmede açılır) - Yalın FaaS handler’larının ardındaki ilke olan “Functions are concise, short, single-purpose” için AWS kaynağı.
• NestJS documentation: Custom providers (yeni sekmede açılır) - Kanonik ağır-DI Node framework’ünün dependency-injection container’ı, provider’ları ve module grafiği; Lambdalith’te uygulanabilir, Fargate’te doğal.
• Spring Boot reference documentation (yeni sekmede açılır) - Classpath taraması, IoC container’ı ve auto-configuration: kanonik ağır-DI JVM örneği ve SnapStart’ın bedava olduğu runtime.
• Hono documentation (yeni sekmede açılır) - Ultra-hafif bir router; bir Lambdalith ya da edge runtime için düşük-init seçeneği.
• The Clean Architecture (Robert C. Martin) (yeni sekmede açılır) - Delivery mekanizmasından bağımsız çekirdek; “çekirdek taşınır, kenarları ayarla”nın temeli.
• Hexagonal Architecture (Ports and Adapters, Alistair Cockburn) (yeni sekmede açılır) - Değişmeyen bir çekirdeğin etrafında runtime başına ayarladığınız kenar olarak ports ve adapters.
• AWS Lambda Web Adapter (yeni sekmede açılır) - Bir Express, Fastify ya da benzeri HTTP sunucusunu bir Lambdalith içinde değiştirmeden çalıştıran AWS bakımlı eklenti.