PEBD6027 · RPS minggu 9 · 2x50 menit
Database & Serverless RDS · DynamoDB · Aurora · Lambda · Event-driven Architecture Hari ini kita masuk dua topik utama: database managed dan serverless compute Lambda. Setelah compute EC2 P5, storage S3 P6, networking VPC P7, sekarang layer di atasnya: managed database dan event-driven. Database adalah komponen paling kritis sebagian besar aplikasi — downtime DB = downtime bisnis. Serverless adalah paradigma tanpa server provisioning, bayar per invocation. Konteks Indonesia: Gojek event-driven pakai Lambda untuk trigger event handler jutaan per hari, Tokopedia migrasi dari RDS ke Aurora untuk skala transaksi Harbolnas. Peta Pembelajaran Hari Ini Sub-CPMK 8: memilih database cloud dan menerapkan fungsi serverless. Empat indikator.
RDS PostgreSQL & MySQL managed DynamoDB NoSQL key-value Aurora MySQL & PostgreSQL Lambda event-driven function API Gateway + Lambda = REST serverless Hitung biaya Lambda vs EC2 Posisi 14P: setelah networking VPC, hari ini database & serverless. P9 IAM & security.
Empat indikator: beda relational vs NoSQL, design RDS multi-AZ, tulis Lambda function sederhana, hitung trade-off Lambda vs EC2. Pemilihan database adalah arsitektur paling fundamental — sulit migrate setelah production. Serverless cocok untuk event-driven dan traffic variable, tapi tidak selalu lebih murah dari EC2 untuk beban konstan. Database di Cloud: Managed vs Self-Hosted Cloud mengubah database operations: dari install-sendiri ke managed service. Trade-off cost vs effort.
RDS Uptime SLA
99,95%
Multi-AZ RDS — 4,3 jam downtime maks per tahun
DBA Time Saved
~70%
Studi TODOgroup 2022 (dihedge) — DBA fokus schema bukan ops
Self-hosted DB di EC2 = full control tapi full responsibility: backup, patching, replication. Bank compliance POJK sulit tanpa DBA dedicated.
Cloud mengubah database operations dari install-sendiri ke managed service. RDS Uptime SLA 99,95 persen dengan multi-AZ setara 4,3 jam downtime maks per tahun. Studi TODOgroup 2022 dihedge menunjukkan managed DB menghemat sekitar 70 persen waktu DBA — mereka fokus schema dan query optimization bukan operasional. Self-hosted DB di EC2 memberi full control tapi full responsibility: backup patching replication. Bank compliance POJK sulit tanpa DBA dedicated untuk self-hosted. Trade-off: cost managed lebih tinggi per jam tapi total cost of ownership lebih rendah untuk kebanyakan kasus. Bagian 1 · 1/4
Relational Database (RDS)
Diskusi: bila startup fintech butuh transaksi konsisten (ACID) untuk saldo nasabah, pilih RDS atau DynamoDB?
Jawaban: RDS PostgreSQL atau MySQL. DynamoDB adalah NoSQL yang tidak mendukung transaction multi-item ACID penuh dengan isolation level tinggi. Untuk saldo nasabah, ACID transaksi wajib — bila 2 operasi harus atomic (debit+credit), relational DB pilihan. DynamoDB cocok untuk data semi-terstruktur dengan throughput tinggi seperti session atau event log. Bank selalu relational untuk core banking. Hybrid arsitektur: RDS untuk transaksi, DynamoDB untuk cache/session. RDS PostgreSQL & MySQL RDS = managed relational database. PostgreSQL, MySQL, MariaDB, Oracle, SQL Server.
Installation & OS patching Automated backup point-in-time Multi-AZ synchronous replication Read replica untuk scaling read Schema design Index optimization Query tuning Connection pooling (PgBouncer) RDS hemat DBA ops ~70% tapi schema dan query tetap tanggung jawab developer.
RDS adalah managed relational database yang mendukung PostgreSQL MySQL MariaDB Oracle SQL Server. Yang dikelola AWS: installation dan OS patching, automated backup point-in-time 35 hari retention, multi-AZ synchronous replication untuk high availability, read replica untuk scaling read workload. Yang Anda lakukan: schema design, index optimization, query tuning, connection pooling via PgBouncer. RDS hemat DBA ops 70 persen tapi schema dan query tetap tanggung jawab developer. Bank core banking Indonesia umumnya pakai PostgreSQL atau Oracle di RDS dengan multi-AZ dan cross-region read replica untuk DR. Aurora: MySQL & PostgreSQL Cloud-Native Aurora = engine cloud-native AWS, kompatibel MySQL/PostgreSQL tapi 5x performa (klaim AWS).
Storage distributed 6 copy/3 AZ Auto-healing storage layer 15 read replica vs 5 di RDS Up to 5x throughput MySQL standar Scale otomatis 0,5-128 ACU Cocok beban variable/intermittent Hemat cost beban rendah Multi-AZ support Aurora lebih mahal per jam dari RDS tapi storage cluster shared. Untuk skala besar, TCO lebih rendah.
Aurora adalah engine cloud-native AWS kompatibel MySQL dan PostgreSQL tapi klaim AWS 5 kali performa. Aurora MySQL PostgreSQL: storage distributed 6 copy di 3 AZ, auto-healing storage layer, 15 read replica dibanding 5 di RDS standar, sampai 5 kali throughput MySQL standar. Aurora Serverless v2 scale otomatis 0,5 sampai 128 ACU cocok beban variable atau intermittent, hemat cost beban rendah, multi-AZ support. Aurora lebih mahal per jam dari RDS tapi storage cluster shared sehingga untuk skala besar TCO lebih rendah. Tokopedia migrasi dari RDS MySQL ke Aurora MySQL untuk skala Harbolnas. Studi Kasus: Tokopedia Migrasi ke Aurora Tokopedia migrasi core DB dari RDS MySQL ke Aurora untuk skala Harbolnas.
Public case study AWS Tokopedia: pre-Aurora, RDS MySQL skala besar menghadapi bottleneck saat Harbolnas (11.11, 12.12). Migrasi ke Aurora MySQL: read replica 5 ke 15, storage distributed, auto-healing. Hasil (dihedge): throughput Harbolnas naik ~3-5x, failover recovery 30s (vs manual 10-15 mnt), DBA fokus schema bukan ops.
RDS MySQL bottleneck Manual failover 10-15 menit 5 read replica max Maintenance window tight Throughput 3-5x naik Failover otomatis 30 detik 15 read replica Storage auto-scaling Pelajaran Bisdig: pemilihan database bukan teknis semata — biaya downtime Harbolnas jauh lebih besar dari premium Aurora.
Tokopedia migrasi core DB dari RDS MySQL ke Aurora untuk skala Harbolnas. Public case study AWS: pre-Aurora, RDS MySQL skala besar menghadapi bottleneck saat Harbolnas 11.11 dan 12.12. Migrasi ke Aurora MySQL: read replica 5 ke 15, storage distributed, auto-healing. Hasil dihedge: throughput Harbolnas naik 3 sampai 5 kali, failover recovery 30 detik dibanding manual 10 sampai 15 menit, DBA fokus schema bukan ops. Pra-Aurora: RDS MySQL bottleneck, manual failover 10 sampai 15 menit, 5 read replica max, maintenance window tight. Pasca-Aurora: throughput 3 sampai 5 kali naik, failover otomatis 30 detik, 15 read replica, storage auto-scaling. Pelajaran Bisdig: pemilihan database bukan teknis semata — biaya downtime Harbolnas jauh lebih besar dari premium Aurora. Bagian 2 · 2/4
NoSQL DynamoDB
Diskusi: bila Gojek butuh simpan lokasi driver real-time update 1000x/detik per driver, pilih DB apa?
Jawaban: DynamoDB atau Redis. DynamoDB cocok untuk key-value massive throughput dengan latency single-digit milidetik. Lokasi driver update 1000x per detik adalah workload write-heavy key-value ideal DynamoDB. Redis juga cocok tapi self-managed atau ElastiCache. DynamoDB auto-scale, pay-per-request, no capacity planning. Gojek case study AWS pakai DynamoDB untuk session, lokasi driver, dan order state. DynamoDB Anatomi DynamoDB = NoSQL key-value fully managed. Skala massive, latency milidetik.
Table: kumpulan item Item: 1 row (max 400KB) Partition key (wajib) Sort key (opsional, untuk composite) Latency single-digit milidetik Throughput unlimited (auto-scale) No schema (NoSQL) TTL item otomatis DynamoDB cocok: session, IoT data, gaming leaderboard, real-time analytics. Tidak cocok: transaksi ACID multi-table.
DynamoDB adalah NoSQL key-value fully managed dengan skala massive dan latency milidetik. Konsep inti: table adalah kumpulan item, item adalah 1 row max 400 KB, partition key wajib, sort key opsional untuk composite primary key. Karakteristik: latency single-digit milidetik, throughput unlimited auto-scale, no schema NoSQL, TTL item otomatis untuk expiry. DynamoDB cocok untuk session, IoT data, gaming leaderboard, real-time analytics. Tidak cocok untuk transaksi ACID multi-table kompleks. Gojek pakai DynamoDB untuk lokasi driver real-time dan order state machine. DynamoDB Capacity Mode Dua mode: provisioned (manual) atau on-demand (auto). Trade-off cost vs simplicity.
Aspek Provisioned On-Demand Cost Model RCU/WCU per jam (cheap saat steady) Per request (murah saat variable) Auto-scaling Ya, tapi capacity plan Built-in, instant Best For Beban predictable/steady Beban unpredictable/spiky Contoh Backend aplikasi internal Harbolnas spike, IoT burst Hemat Cost Beban konstan: 3-5x Beban spiky: 30-50%
Mulai dari on-demand (murah & simple), optimize ke provisioned saat beban stabil terlihat.
DynamoDB punya dua capacity mode: provisioned manual atau on-demand auto. Provisioned cost model RCU WCU per jam murah saat steady, auto-scaling ada tapi capacity plan dibutuhkan, best for beban predictable steady, contoh backend aplikasi internal, hemat cost beban konstan 3 sampai 5 kali. On-demand cost model per request murah saat variable, auto-scaling built-in instant, best for beban unpredictable spiky, contoh Harbolnas spike IoT burst, hemat cost beban spiky 30 sampai 50 persen. Aturan praktis: mulai dari on-demand karena murah dan simple, optimize ke provisioned saat beban stabil terlihat dan cost analysis jelas. Hitung dari Nol: DynamoDB vs RDS untuk Session Store Aplikasi web 100K MAU, 1M session/bulan, 1KB per session, TTL 24 jam. DynamoDB vs RDS?
Komponen DynamoDB On-Demand RDS db.t4g.micro Write 1M/bulan 1M WRU ÷ 1000 × $1,25 $1,25 Read 5M/bulan 5M RRU ÷ 1000 × $0,25 $1,25 Storage 100 GB 100 × $0,25 $25/bulan Server cost — $15/bulan (instance) Multi-AZ Built-in +100% (multi-AZ RDS) Backup Built-in PITR +20% storage Total $27,50/bln $45-60/bln Latency read 5-10 ms (single-digit) 2-20 ms (bervariasi)
Harga AWS public (dihedge). DynamoDB menang di latency konsisten + built-in scaling, RDS menang di query SQL kompleks.
Mari hitung konkret DynamoDB vs RDS untuk session store 100 ribu MAU, 1 juta session per bulan, 1 KB per session, TTL 24 jam. DynamoDB On-Demand: write 1 juta WRU dibagi 1000 kali 1,25 dolar setara 1,25 dolar. Read 5 juta RRU dibagi 1000 kali 0,25 dolar setara 1,25 dolar. Storage 100 GB kali 0,25 dolar setara 25 dolar. Total 27,50 dolar per bulan. RDS db.t4g.micro: server cost 15 dolar per bulan, multi-AZ plus 100 persen jadi 30 dolar, backup plus 20 persen storage. Total 45 sampai 60 dolar. Latency read DynamoDB single-digit 5 sampai 10 milidetik, RDS 2 sampai 20 milidetik bervariasi. DynamoDB menang di latency konsisten dan built-in scaling. Bagian 3 · 3/4
Lambda Serverless
Diskusi: bila startup punya cron job image resize 1000x/hari, pilih EC2 atau Lambda?
Jawaban: Lambda. EC2 untuk cron job intermittent tidak efisien — Anda bayar instance 24/7 padahal job cuma jalan 5 menit/hari. Lambda pay-per-request: 1000 invocation × 128 MB × 2 detik = sangat murah. Lambda cocok untuk event-driven, intermittent, atau burst. Tidak cocok untuk long-running atau stateful. AWS Lambda free tier 1 juta request/bulan + 400 ribu GB-detik. Lambda Anatomi Lambda = function serverless. Trigger oleh event, auto-scale, pay-per-use.
Function: kode + runtime Handler: entry point function Trigger: event source (S3, API GW) Execution: max 15 menit Auto-scale 0 → ribuan concurrent Cold start 100-500ms (Java lebih lama) Stateless (gunakan DynamoDB/S3) Memory 128 MB - 10 GB Lambda cocok: event-driven, burst, intermittent. Tidak cocok: long-running, stateful, WebSocket.
Lambda adalah function serverless yang trigger oleh event, auto-scale, pay-per-use. Konsep inti: function adalah kode plus runtime Node.js Python Java Go, handler adalah entry point function, trigger event source seperti S3 API Gateway DynamoDB stream, execution max 15 menit. Karakteristik: auto-scale 0 sampai ribuan concurrent, cold start 100 sampai 500 milidetik Java lebih lama, stateless gunakan DynamoDB S3 untuk persist, memory 128 MB sampai 10 GB. Lambda cocok untuk event-driven burst intermittent. Tidak cocok untuk long-running stateful WebSocket. Free tier 1 juta request per bulan plus 400 ribu GB-detik. API Gateway + Lambda = REST Serverless Pola paling populer serverless: API Gateway routing ke Lambda function.
Routing HTTP/REST/HTTP API Throttling & rate limit Authentication (Cognito, Lambda Authorizer) WAF integration untuk security Parse request event Business logic Query DynamoDB/RDS Return response JSON Pola ini dipakai Gojek untuk webhook event handler dan Tokopedia untuk image upload trigger.
Pola paling populer serverless adalah API Gateway routing ke Lambda function. API Gateway: routing HTTP REST HTTP API, throttling dan rate limit, authentication via Cognito atau Lambda Authorizer, WAF integration untuk security. Lambda Handler: parse request event, business logic, query DynamoDB atau RDS, return response JSON. Pola ini dipakai Gojek untuk webhook event handler dan Tokopedia untuk image upload trigger. Keunggulan: no server to manage, auto-scale, pay-per-request. Limit: cold start latency, max 15 menit execution, tidak cocok untuk stateful. Untuk latency kritis, gunakan provisioned concurrency. Event-Driven Architecture: SQS, SNS, EventBridge Event-driven = komponen terpisah, async via message bus. Loose coupling, scalable.
Message queue pull-based Decouple producer/consumer At-least-once delivery Use: order processing async Pub/sub push-based 1 fan-out ke banyak subscriber Filter via attribute Use: notification broadcast Event bus central Schema registry Cross-service routing Use: workflow orchestration Event-driven = loose coupling + scalable. Trade-off: debugging sulit, eventual consistency.
Event-driven architecture adalah komponen terpisah async via message bus, loose coupling dan scalable. SQS Queue adalah message queue pull-based decouple producer consumer, at-least-once delivery, use case order processing async. SNS Topic adalah pub/sub push-based 1 fan-out ke banyak subscriber, filter via attribute, use case notification broadcast. EventBridge adalah event bus central dengan schema registry cross-service routing, use case workflow orchestration. Event-driven memberi loose coupling dan scalable. Trade-off: debugging lebih sulit karena distributed, eventual consistency bukan immediate. Gojek pakai SQS untuk order processing, SNS untuk notification driver dan user. Bagian 4 · 4/4
Penutup & Pemilihan Teknologi
Diskusi: bila startup fintech baru mulai dengan 10 user, pilih apa semua stack dari hari ini?
Jawaban: start simple. RDS PostgreSQL untuk core data, DynamoDB untuk session atau event log, Lambda untuk event-driven, EC2 atau ECS untuk app server. Jangan over-engineer — premature optimization adalah dosa. Seiring skala, evaluate. Aurora saat RDS MySQL bottleneck. Serverless v2 saat beban variable jelas. AWS Well-Architected Framework jadi panduan. Bisdig lens: pemilihan teknologi adalah trade-off cost vs complexity vs time-to-market, bukan purely teknis. Lambda Pricing Model Lambda charge per request + duration. Free tier sangat generous untuk startup.
Komponen Free Tier Paid Tier Request 1 juta/bulan gratis $0,20 per 1 juta Compute (GB-detik) 400K GB-detik/bln $1,00 per 1 juta GB-detik Contoh 1M req 1s 128MB Gratis semua 1M × 128/1024 × 1s × $1/1M = $0,125 Contoh 10M req 5s 256MB — $3,05 + $3,125 = $6,17/bln Provisioned Concurrency — $0,0000156/GB-detik (slalu on)
Lambda murah untuk beban spiky. Untuk beban konstan 24/7, EC2/Fargate sering lebih murah.
Lambda charge per request plus duration. Free tier sangat generous: 1 juta request per bulan gratis dan 400 ribu GB-detik per bulan gratis. Paid tier: 0,20 dolar per 1 juta request, 1,00 dolar per 1 juta GB-detik. Contoh 1 juta request 1 detik 128 MB: 1 juta kali 128 dibagi 1024 kali 1 detik kali 1 dolar per 1 juta setara 0,125 dolar. Contoh 10 juta request 5 detik 256 MB: 3,05 dolar request plus 3,125 dolar compute setara 6,17 dolar per bulan. Provisioned Concurrency untuk menghilangkan cold start dengan harga 0,0000156 dolar per GB-detik always on. Lambda murah untuk beban spiky. Untuk beban konstan 24/7, EC2 atau Fargate sering lebih murah karena tidak ada overhead per-request. Pemilihan Database: Decision Framework Tidak ada satu DB untuk semua. Framework pemilihan berdasar use case.
Use Case Pilihan Utama Alasan Transaksi ACID (saldo, order) RDS PostgreSQL / Aurora ACID multi-table konsisten Session/Cookie ElastiCache Redis Sub-ms latency, TTL built-in Lokasi real-time (Gojek) DynamoDB / Redis Geo Massive write, single-digit ms Document JSON fleksibel DynamoDB / DocumentDB Schema-less, scale horizontal Data lake analytics S3 + Athena Petabyte, pay-per-query Search full-text OpenSearch Service Inverted index, ranking
Aturan Bisdig: pilih yang paling sederhana yang bisa scale. Migration DB mahal, jangan premature optimize.
Tidak ada satu DB untuk semua. Framework pemilihan berdasar use case: transaksi ACID saldo dan order pilih RDS PostgreSQL atau Aurora karena ACID multi-table konsisten. Session atau cookie pilih ElastiCache Redis karena sub-milidetik latency TTL built-in. Lokasi real-time seperti Gojek pilih DynamoDB atau Redis Geo karena massive write single-digit milidetik. Document JSON fleksibel pilih DynamoDB atau DocumentDB karena schema-less scale horizontal. Data lake analytics pilih S3 plus Athena karena petabyte pay-per-query. Search full-text pilih OpenSearch Service karena inverted index ranking. Aturan Bisdig: pilih yang paling sederhana yang bisa scale. Migration DB mahal, jangan premature optimize. Lambda Cold Start & Mitigasi Cold start = latency 100-500ms saat Lambda instantiate baru. Penting dipahami untuk latensi-sensitive.
Function baru pertama invoke Setelah idle beberapa menit Java/C# lebih lama (JVM startup) VPC-enabled Lambda dulu lebih lama (kini OK) Provisioned Concurrency (warm) Smaller package (Java ggrave), Python cepat SnapStart Java (Amazon 2023) EventBridge Scheduler keep-warm Latensi kritis (API mobile user): provisioned concurrency wajib. Latensi long-tail OK: on-demand cukup.
Cold start adalah latency 100 sampai 500 milidetik saat Lambda instantiate function baru. Penting dipahami untuk latensi-sensitive workload. Penyebab cold start: function baru pertama invoke, setelah idle beberapa menit dengan tidak ada traffic, Java atau C-sharp lebih lama karena JVM startup dan CLR init, VPC-enabled Lambda dulu lebih lama tapi kini OK sejak AWS Hyperplane. Mitigasi: Provisioned Concurrency untuk warm always-on dengan tambahan cost, smaller package karena Java ggrave lebih cepat Python cepat, SnapStart Java fitur Amazon 2023 untuk JVM snapshot, EventBridge Scheduler keep-warm dengan cron invoke tiap 5 menit. Latensi kritis seperti API mobile user: provisioned concurrency wajib. Latensi long-tail OK untuk background job: on-demand cukup. Gojek pakai provisioned concurrency untuk API latensi-sensitif driver location, on-demand untuk webhook processing. Ringkasan Kunci Pertemuan 8 Hari ini Anda menguasai database cloud (relational + NoSQL) dan Lambda serverless.
Relational vs NoSQL
RDS Aurora untuk ACID. DynamoDB untuk massive throughput.
Lambda
Event-driven, pay-per-request. Cocok burst/intermittent, bukan konstan.
Event-Driven
SQS queue + SNS pub/sub + EventBridge bus = loose coupling.
Tiga lensa P8: ACID vs throughput · Lambda pay-per-request · event-driven loose coupling.
Persiapan P9: IAM & Security. Baca Wittig bab 5 IAM. Kuis 5 menit soal RDS multi-AZ vs Aurora.
Tiga pesan kunci: relational vs NoSQL RDS Aurora untuk ACID transaksi konsisten, DynamoDB untuk massive throughput skala horizontal. Lambda event-driven pay-per-request cocok burst intermittent, bukan beban konstan. Event-driven SQS queue plus SNS pub/sub plus EventBridge bus sama dengan loose coupling dan scalable. Tiga lensa P8: ACID vs throughput, Lambda pay-per-request, event-driven loose coupling. P9 kita masuk IAM dan security — baca Wittig bab 5 IAM. Kuis 5 menit RDS multi-AZ vs Aurora di awal P9. Sampai jumpa.