Kenapa DynamoDB, bukan Aurora?
Kenapa Aurora PostgreSQL, bukan Aurora DSQL?
Kenapa OpenSearch dipakai di sini?
Apakah tabel ini source of truth atau projection?
Apa access pattern yang dipenuhi?
Apa trade-off consistency-nya?
Apa rencana kalau workload berubah?
Siapa owner keputusan ini?

Kami memilih X karena workload Y, invariant Z, dan constraint A/B/C.
Kami menolak opsi P/Q karena trade-off tertentu.
Kami menerima risiko R dengan mitigasi M.
Kami akan meninjau ulang jika trigger T terjadi.

[ ] Memilih database/service baru.
[ ] Menentukan source of truth untuk domain penting.
[ ] Memisahkan read model/projection baru.
[ ] Mengubah consistency model.
[ ] Mengubah partition/key strategy.
[ ] Menambah cache yang memengaruhi correctness.
[ ] Menambah search/analytics projection yang dipakai user.
[ ] Melakukan migration database.
[ ] Mengubah backup/restore/retention posture.
[ ] Mengubah multi-region strategy.
[ ] Mengizinkan shared database atau cross-service query.
[ ] Mengubah schema evolution strategy.
[ ] Menambah direct writer baru ke authoritative store.

# ADR-DB-<number>: <decision title>

## Status

Proposed | Accepted | Superseded | Deprecated | Rejected

## Date

YYYY-MM-DD

## Owners

- Decision owner:
- Domain owner:
- Data owner:
- Operational owner:

## Context

Apa masalah yang diselesaikan?
Workload apa yang sedang/akan terjadi?
Apa constraint business, regulatory, latency, cost, migration, dan team?

## Decision

Keputusan final dalam 3-7 kalimat.

## Data Ownership

- Source of truth:
- Derived stores:
- Allowed writers:
- Allowed readers:
- Repair/rebuild path:

## Workload Characterization

- Read/write ratio:
- Peak traffic:
- Data volume:
- Item/row size:
- Query patterns:
- Mutation patterns:
- Hot key/skew risk:
- Retention:
- Latency objective:
- Availability objective:

## Access Patterns

| Pattern | Frequency | Latency Target | Consistency | Query Shape | Store Support |
|---|---:|---:|---|---|---|

## Consistency and Transaction Boundary

- Required invariants:
- Transaction boundary:
- Isolation/conditional write strategy:
- Cross-service consistency:
- Retry/idempotency strategy:

## Options Considered

### Option A
Pros:
Cons:
Risks:

### Option B
Pros:
Cons:
Risks:

## Decision Drivers

- correctness:
- latency:
- scalability:
- operational simplicity:
- cost:
- security/compliance:
- migration feasibility:
- reversibility:

## Consequences

Positive:
Negative:
Neutral:

## Failure Modes and Mitigations

| Failure Mode | Impact | Detection | Mitigation | Owner |
|---|---|---|---|---|

## Observability

- Metrics:
- Logs:
- Traces:
- Dashboards:
- Alerts:
- Reconciliation checks:

## Security and Compliance

- Data classification:
- Encryption:
- IAM boundary:
- Network boundary:
- Audit:
- Retention/deletion:

## Cost Model

- Main cost drivers:
- Expected baseline:
- Scaling trigger:
- Cost alarms:

## Migration and Rollout

- Rollout plan:
- Backfill:
- Dual write/CDC:
- Validation:
- Rollback:

## Reversibility

- Can this decision be reversed?
- Exit strategy:
- Data export path:
- Contract compatibility:

## Review Triggers

- Traffic grows above:
- Cost grows above:
- Latency exceeds:
- New access pattern appears:
- Consistency bug occurs:
- Service feature changes:

## References

- Links to docs, benchmark, design docs, experiments, tickets.

DynamoDB dipilih karena scalable.

DynamoDB dipilih karena access pattern utama adalah key-based lookup by tenant+caseId dan query inbox by assignee+dueDate. Workload expected 4.000 writes/sec peak, item size < 8 KB, no ad-hoc joins, no multi-item invariant beyond conditional uniqueness per aggregate. Strongly consistent reads hanya dibutuhkan pada command confirmation path; GSI staleness acceptable untuk inbox dengan budget 10 detik.

Decision: Use DynamoDB.
Reason: It scales.

Invariant apa yang harus selalu benar?
Apakah butuh ACID transaction?
Apakah conditional write cukup?
Apakah eventual consistency acceptable?
Apa risiko duplicate/retry?

Case status transition harus linear per case.
Dua final decision tidak boleh committed untuk case yang sama.

Query utama apa?
Apakah query known upfront?
Apakah query ad-hoc?
Apakah perlu join?
Apakah perlu range query?
Apakah perlu graph traversal?
Apakah perlu time-window aggregation?

Scale by row count?
Scale by tenant count?
Scale by write throughput?
Scale by read fanout?
Scale by item size?
Scale by query complexity?
Scale by connection count?

Siapa yang akan tune query/index?
Siapa yang menangani failover?
Siapa yang debug slow query/hot partition?
Siapa yang manage schema evolution?
Siapa yang restore saat corruption?

Berapa sulit pindah dari keputusan ini?
Apakah data bisa diekspor?
Apakah contract membocorkan teknologi store?
Apakah key design mengunci masa depan?
Apakah migration bisa incremental?

Show open tasks assigned to a user sorted by due date.
Filter by priority/status.
Update quickly after case assignment/status changes.
Support high read volume from UI.

PK = USER#<userId>
SK = DUE#<yyyy-mm-dd>#PRIORITY#<p>#CASE#<caseId>

CaseAssigned
CaseUnassigned
CaseStatusChanged
CaseSlaChanged

Authoritative assignment wins.
Inbox may lag by 10 seconds.
Actions from inbox must submit command with expected case version.

case identity
case lifecycle status
case parties
case evidence association
case version
case transition ledger

Case status transition must be valid.
Only one current status per case.
Every status change must have audit entry.
Case command must be idempotent.
Concurrent command must detect version conflict.

One command = one database transaction.
Within transaction:
  - validate current state/version
  - update case current state
  - insert ledger row
  - insert outbox event

Write p95 > 100 ms for 3 days.
Lock wait spikes on status transition.
Connection utilization > 80% sustained.
Case search workload starts affecting OLTP.
Multi-region active-active write requirement appears.

Authoritative case fields: Aurora Case Core
Authoritative document metadata: Aurora Document Registry
Authoritative document text extraction: Document Processing domain
Search projection: OpenSearch case_search_vN index

Search results are discovery hints.
Any command action must reload authoritative case detail.
Projection staleness budget: 60 seconds.

[ ] Apakah source of truth jelas?
[ ] Apakah derived state diklasifikasikan?
[ ] Apakah allowed writers eksplisit?
[ ] Apakah read model punya staleness budget?
[ ] Apakah repair/rebuild path jelas?

[ ] Invariant ditulis, bukan diasumsikan.
[ ] Transaction boundary jelas.
[ ] Consistency model cocok dengan business requirement.
[ ] Idempotency/retry strategy ada.
[ ] Conflict behavior jelas.

[ ] Access patterns ditulis.
[ ] Cardinality dan hot key risk dianalisis.
[ ] Latency target realistis.
[ ] Throughput estimate punya dasar.
[ ] Backfill/replay load dipertimbangkan.

[ ] Metrics/logs/traces disebutkan.
[ ] Dashboard/alert jelas.
[ ] Backup/restore atau rebuild diuji.
[ ] Runbook failure utama ada.
[ ] Cost driver dipahami.

[ ] Schema evolution strategy ada.
[ ] Migration/cutover plan ada jika relevan.
[ ] Reversibility dinilai.
[ ] Review triggers ditentukan.
[ ] Superseding ADR path jelas.

scales writes by partition key cardinality
scales reads via replicas
scales search query via inverted index
scales time-series ingestion by dimension/time partition

reversible
evolvable
observable
migration-friendly
contract-protected

operational query
admin support query
analytics query
investigation query
product search query

why separate ownership is needed
how consistency is handled
how reporting works
how cross-service query is avoided

export path
dual write/CDC strategy
backfill duration
contract compatibility
cutover validation
rollback window

architecture/
  adr/
    database/
      0001-use-aurora-postgresql-for-case-core.md
      0002-use-dynamodb-for-task-inbox-projection.md
      0003-use-opensearch-for-case-discovery.md
      0004-use-transactional-outbox-for-case-events.md
    application-integration/
      0001-use-eventbridge-for-domain-events.md
      0002-use-sqs-for-projection-workers.md
  diagrams/
  data-contracts/
    case-events/
    read-models/

# Database ADR Index

| ADR | Status | Domain | Decision | Superseded By |
|---|---|---|---|---|
| ADR-DB-001 | Accepted | Case Core | Aurora PostgreSQL | - |
| ADR-DB-002 | Accepted | Work Allocation | DynamoDB Inbox Projection | - |
| ADR-DB-003 | Accepted | Search | OpenSearch Projection | - |

[ ] Does this PR change database ownership?
[ ] Does this PR add a writer to an authoritative store?
[ ] Does this PR add a new projection/cache/index?
[ ] Does this PR change access pattern materially?
[ ] Does this PR violate an accepted ADR?
[ ] Does this PR require new ADR or ADR update?

PR adds direct update to case_core.cases.status from BatchCorrectionJob.

ADR-DB-021 says allowed writer is CaseCommandService only.

Use CaseCommandService correction command, or create new ADR for emergency repair path.

reviewTriggers:
  - name: aurora_connection_utilization
    threshold: "> 80% for 30 minutes"
    dashboard: cloudwatch/rds-case-core
  - name: lock_wait_p95
    threshold: "> 200 ms for 15 minutes"
  - name: dynamodb_hot_partition_suspected
    signal: throttling on task_inbox despite available table capacity
  - name: projection_lag
    threshold: "> 60s for case_search"
  - name: monthly_cost
    threshold: "> 150% forecast"

Cost drivers:
- read/write request units,
- item size,
- GSI count/projection size,
- streams usage,
- global tables replication,
- backup/PITR/export,
- on-demand vs provisioned mode.

Cost drivers:
- instance class / ACU if serverless,
- storage and I/O,
- backup/snapshot retention,
- read replicas,
- cross-region replication,
- Performance Insights retention,
- data transfer.

Cost drivers:
- data nodes,
- storage size,
- replica count,
- indexing rate,
- query complexity,
- shard strategy,
- snapshot retention.

Cost is expected to grow primarily with X.
We will review if X exceeds Y.

Data classification apa?
Apakah PII/regulated/confidential?
Encryption at rest/in transit?
IAM principal mana yang bisa read/write?
Apakah network private?
Apakah backup terenkripsi?
Apakah audit log dibutuhkan?
Retention berapa lama?
Delete semantics apa?
Apakah legal hold berlaku?
Apakah cross-region/cross-account allowed?

Can decision be reconstructed?
Can unauthorized mutation be detected?
Are manual repairs approved and logged?
Is evidence immutable enough for policy/legal need?

How would we leave this decision?
What data export is possible?
What contract hides the database choice?
Can we run dual read/write temporarily?
Can we rebuild derived state elsewhere?
What is irreversible?

- domain owner,
- allowed writers,
- invariants,
- transaction model,
- backup/restore,
- audit,
- migration strategy,
- schema evolution,
- security boundary,
- manual repair policy.

- source facts,
- projection builder,
- staleness budget,
- rebuild path,
- idempotency,
- replay safety,
- mismatch reconciliation,
- whether user actions can start from this projection.

1. update authoritative case state,
2. notify downstream consumers,
3. avoid dual-write inconsistency.

outbox_oldest_unpublished_age > 60 seconds
outbox table > retention budget
new event consumers require replay beyond retention

Main ADR: decision and trade-off.
Appendix/link: benchmark, diagrams, long analysis.

design doc
load test report
spreadsheet cost model
schema contract
migration plan
runbook

[ ] Apa fakta yang disimpan?
[ ] Siapa owner-nya?
[ ] Apakah store ini authoritative atau derived?
[ ] Apa access pattern utama?
[ ] Apa invariant correctness?
[ ] Apa consistency model?
[ ] Apa failure mode utama?
[ ] Apa observability signal-nya?
[ ] Apa cost driver-nya?
[ ] Apa security/compliance boundary-nya?
[ ] Apa migration/reversibility story-nya?
[ ] Kapan keputusan ini harus ditinjau ulang?

Kami pilih ini karena familiar.
Kami pilih ini karena scalable.
Kami pilih ini karena managed.
Kami pilih ini karena tim lain memakainya.

Kami pilih ini karena access pattern, invariant, consistency, scale, operations, cost, security, migration, dan reversibility-nya cocok dengan workload ini.

mengerti,
mengoperasikan,
menguji,
menantang,
dan mengganti keputusan itu saat realitas berubah.