Stateless vs Stateful #
Apakah sebuah aplikasi stateless atau stateful adalah salah satu keputusan arsitektur yang paling berdampak di cloud. Perbedaan ini tidak terlihat saat sistem kecil dan berjalan pada satu server — tapi menjadi sangat nyata ketika kamu perlu scale out, deploy ulang tanpa downtime, atau recover dari kegagalan. Stateless adalah fondasi yang memungkinkan elastisitas, horizontal scaling, dan resiliensi di cloud.
Definisi yang Presisi #
State adalah informasi yang perlu diingat antara satu request dan request berikutnya. Stateless dan stateful merujuk pada di mana — atau apakah — informasi itu disimpan.
Stateless:
Setiap request membawa semua informasi yang dibutuhkan
Server tidak menyimpan informasi apapun antar request
Server A dan Server B bisa menangani request dari user yang sama
karena tidak ada "memori" yang tersimpan di server manapun
Stateful:
Server menyimpan informasi tentang session atau konteks request sebelumnya
Request berikutnya dari user yang sama harus diarahkan ke server
yang sama (sticky session) karena server lain tidak punya konteksnya
Ilustrasi:
Stateless — Kasir Supermarket:
Customer datang → bawa semua barang → bayar → selesai
Kasir tidak perlu ingat customer ini sebelumnya
Customer bisa antri di kasir manapun
Stateful — Dokter yang sedang memeriksa pasien:
Dokter perlu ingat riwayat kunjungan sebelumnya
Pasien harus kembali ke dokter yang sama untuk kontinuitas
Mengapa Stateless adalah Fondasi Cloud-Native #
Stateless bukan hanya preferensi estetika arsitektur — ia adalah prasyarat untuk karakteristik cloud yang paling penting.
Dampak Stateless terhadap Kemampuan Cloud:
Horizontal Scaling:
Stateless: tambah instance baru → langsung bisa terima trafik
Stateful: tambah instance baru → tidak punya state existing user
→ harus ada sticky session atau migrasi state
→ scaling jauh lebih rumit
Deployment tanpa Downtime:
Stateless: deploy versi baru → route trafik → terminate instance lama
User tidak terpengaruh karena tidak ada state di instance
Stateful: terminate instance lama = hilang semua state aktif
→ butuh mekanisme migrasi state yang kompleks
Auto-Healing:
Stateless: instance mati → instance baru langsung siap
Request berikutnya dari user tidak terpengaruh
Stateful: instance mati → state hilang → user harus mulai ulang
Disaster Recovery:
Stateless: spinning up instance baru di region lain = selesai
Stateful: perlu replikasi state ke region lain secara real-time
Anti-Pattern State di Memori Server #
Menyimpan state di memori server adalah sumber masalah yang sangat umum ketika pindah ke cloud atau mulai scale out.
// ANTI-PATTERN: State di memori instance
// (Python Flask sebagai contoh konseptual)
sessions = {} # Dictionary di memori server
def login(user_id):
token = generate_token()
sessions[token] = {
'user_id': user_id,
'cart': [],
'preferences': load_preferences(user_id)
}
return token
def get_cart(token):
return sessions[token]['cart'] # Hanya ada di server ini!
# Masalah:
# - Request login masuk ke Server A → session ada di Server A
# - Request get_cart masuk ke Server B → sessions[token] tidak ada → error
# - Server A mati → semua session hilang
# - Tidak bisa scale out tanpa sticky session
// BENAR: State di external store
import redis
def login(user_id):
token = generate_token()
redis_client.setex(
f"session:{token}",
3600, # expire 1 jam
json.dumps({
'user_id': user_id,
'cart': [],
})
)
return token
def get_cart(token):
data = redis_client.get(f"session:{token}")
return json.loads(data)['cart']
# Server A, B, atau C bisa handle request ini
# Server mati tidak mempengaruhi session
# Scale out bebas tanpa sticky session
Cara Mengelola State Secara Eksternal #
Stateless bukan berarti “tidak ada state sama sekali” — ia berarti state disimpan di luar instance komputasi.
Peta External State Store:
User Session dan Auth Token:
→ Distributed cache (Redis, Memcached)
→ Atau: JWT yang di-sign (token membawa state, tidak perlu store)
Data Aplikasi:
→ Database relasional (PostgreSQL, MySQL)
→ Database NoSQL (MongoDB, DynamoDB) sesuai kebutuhan
File dan Media:
→ Object storage (S3-compatible)
→ Jangan simpan file di disk lokal instance
Antrean Pekerjaan:
→ Message queue (SQS, RabbitMQ, Kafka)
→ Jangan simpan job state di memori
Konfigurasi:
→ Environment variables (bukan file di disk instance)
→ Secrets manager untuk credentials
Kapan Stateful Tidak Bisa Dihindari #
Ada workload yang secara fundamental stateful dan tidak bisa di-redesign menjadi stateless dengan mudah.
Workload yang Inherently Stateful:
Database:
→ Database adalah komponen stateful par excellence
→ Data harus persisten di suatu tempat
→ Solusi: gunakan managed database (state dikelola provider)
atau persistent volumes untuk database di container
Streaming dan Real-time Processing:
→ Stateful stream processing (Kafka Streams, Flink)
→ State diperlukan untuk aggregasi, joins, windowing
→ Solusi: framework ini punya mekanisme state management sendiri
Multiplayer Game / Collaborative Apps:
→ State real-time yang harus disinkronisasi
→ Solusi: dedicated stateful service dengan replikasi,
terpisah dari stateless application layer
Long-running Transactions:
→ Transaksi multi-step yang butuh track progress
→ Solusi: saga pattern, state disimpan di database
Prinsip:
Stateful OK jika ada di komponen yang dirancang untuk itu
(database, cache, message broker) — bukan di application server
Ringkasan #
- State adalah informasi yang diingat antara request — stateless berarti tidak ada memori antar request di server, stateful berarti ada.
- Stateless adalah fondasi horizontal scaling — instance baru bisa langsung menerima trafik karena tidak butuh konteks dari instance sebelumnya.
- State di memori server adalah anti-pattern utama — ia membuat scaling, deployment, dan recovery menjadi jauh lebih kompleks.
- Stateless bukan “tanpa state” — state dipindahkan ke external store: Redis untuk session, database untuk data, object storage untuk file.
- JWT adalah alternatif stateless untuk session — token membawa state yang di-sign, tidak perlu lookup ke server lain.
- Database dan cache adalah komponen stateful yang sah — stateless yang dimaksud adalah di application/compute layer, bukan di storage layer.
← Sebelumnya: Vendor Lock-in Berikutnya: Horizontal vs Vertical Scaling →