Final StretchOrdered learning track

Final Capstone and Next Steps

Learn Java Microservices File Handling, State, Configuration and Secret Management - Part 070

Final capstone and next steps untuk Java microservices file, state, configuration, dan secret management: end-to-end design exercise, scoring rubric, implementation roadmap, and advanced continuation path.

7 min read1325 words
Prev
Finish
Lesson 7070 lesson track59–70 Final Stretch
#java#microservices#capstone#architecture+3 more

Part 070 — Final Capstone and Next Steps

The goal of this series was not to memorize patterns.

The goal was to make you dangerous in the right way: able to see failure before it becomes production history.

This is the final part of the series.

We started with mental models:

  • file is not just bytes;
  • state is never absent, only relocated;
  • configuration is runtime behavior control;
  • secret is capability with lifecycle;
  • ownership must be explicit;
  • invariants are stronger than validation.

Then we built implementation depth:

  • Java File I/O;
  • safe local file handling;
  • large file streaming;
  • upload/download design;
  • object storage;
  • presigned URLs;
  • content-addressable storage;
  • versioning/retention/legal hold;
  • state reconstruction;
  • Spring Boot configuration;
  • Kubernetes ConfigMaps and Secrets;
  • Vault/cloud secret managers;
  • GitOps secret delivery;
  • secret rotation;
  • threat modeling;
  • leakage prevention;
  • encryption;
  • access control;
  • auditability;
  • observability;
  • chaos testing;
  • compliance;
  • reference architecture;
  • case studies;
  • engineering playbook.

This final capstone asks you to combine all of it.


1. Capstone Scenario

Design a production-grade Java microservice platform for:

Regulatory Case Evidence and Document Processing

The system must support:

  • uploading evidence files;
  • direct browser upload for large files;
  • proxy upload for small internal files;
  • malware scanning;
  • checksum verification;
  • file lifecycle state machine;
  • metadata and object storage consistency;
  • evidence package export;
  • retention and legal hold;
  • case lifecycle integration;
  • audit and forensics;
  • multi-environment config;
  • zero-downtime secret rotation;
  • Kubernetes deployment;
  • object storage;
  • PostgreSQL metadata;
  • Redis cache for non-authoritative data;
  • OpenTelemetry observability;
  • GitOps deployment.

Non-functional requirements:

- valid upload accepted for processing within 2 seconds
- 99% scanned within 10 minutes
- no accepted file without checksum
- no download without fresh authorization
- presigned download URL TTL <= 5 minutes
- evidence retained 7 years after case closure unless legal hold active
- DB credential rotated every 30 days without downtime
- config changes traceable to Git PR
- production scan cannot be disabled by config
- audit events durably stored within 60 seconds

2. Capstone Architecture

Boundary summary:

BoundaryOwner
Evidence lifecycleEvidence service
Case lifecycleCase service
Authorization policyAccess control service
Payload custodyObject storage platform
Metadata truthEvidence DB
Secret authoritySecret manager/security platform
Config desired stateGitOps/config platform
Audit proofAudit platform
TelemetryObservability platform

3. Capstone Domain Model

public record EvidenceId(String value) {}
public record CaseId(String value) {}
public record FileId(String value) {}

public enum EvidenceStatus {
    DRAFT,
    UPLOAD_PENDING,
    QUARANTINED,
    SCANNING,
    ACCEPTED,
    REJECTED,
    LOCKED_BY_CASE,
    ARCHIVED,
    DELETION_REQUESTED,
    DELETED
}

public record FileIntegrity(
    long sizeBytes,
    String sha256,
    String detectedContentType,
    Instant verifiedAt
) {}

public record RetentionState(
    String policyVersion,
    Instant retentionUntil,
    boolean legalHold
) {}

Core invariant:

EvidenceStatus.ACCEPTED requires:
- fileId exists
- object exists
- checksum verified
- scan decision CLEAN
- metadata committed
- audit event emitted

4. Capstone Lifecycle

Invalid transitions:

UPLOAD_PENDING -> ACCEPTED
REJECTED -> ACCEPTED
DELETED -> ACCEPTED
LOCKED_BY_CASE -> DELETED without retention/legal decision

5. Capstone Upload Design

5.1 Direct Upload

Use for large browser uploads.

1. POST /cases/{caseId}/evidence/upload-sessions
2. authorize actor
3. create metadata status=UPLOAD_PENDING
4. issue presigned PUT to quarantine/temp key
5. client uploads object
6. client completes session
7. API verifies object metadata
8. transition to QUARANTINED
9. enqueue scan

5.2 Proxy Upload

Use for internal small files.

1. stream multipart request
2. enforce size/quota
3. compute checksum while streaming
4. write to temp/quarantine storage
5. create metadata
6. enqueue scan

Do not use:

multipartFile.getBytes()

for unbounded files.


6. Capstone Storage Design

Object key:

quarantine/{yyyy}/{mm}/{dd}/{fileId}/payload
accepted/{yyyy}/{mm}/{dd}/{fileId}/payload
archive/{yyyy}/{mm}/{dd}/{fileId}/payload

Avoid:

cases/{caseId}/{originalFilename}

Object metadata/tags:

fileId
tenantId
ownerService=evidence-service
lifecycle=quarantine
checksumSha256
correlationId

Keep values safe and bounded.

Storage controls:

  • private bucket;
  • encryption with KMS;
  • versioning;
  • object lock/legal hold if required;
  • incomplete multipart abort;
  • temp lifecycle cleanup;
  • object data events where needed;
  • least privilege per service account.

7. Capstone Metadata Schema

CREATE TABLE evidence_file (
    evidence_id TEXT PRIMARY KEY,
    file_id TEXT NOT NULL UNIQUE,
    case_id TEXT NOT NULL,
    tenant_id TEXT NOT NULL,
    status TEXT NOT NULL,

    bucket TEXT NOT NULL,
    object_key TEXT NOT NULL,
    object_version TEXT NULL,

    original_filename_display TEXT NULL,
    detected_content_type TEXT NULL,
    size_bytes BIGINT NULL,
    sha256 TEXT NULL,

    scan_decision TEXT NULL,
    scan_policy_version TEXT NULL,
    scan_completed_at TIMESTAMPTZ NULL,

    retention_policy_version TEXT NULL,
    retention_until TIMESTAMPTZ NULL,
    legal_hold BOOLEAN NOT NULL DEFAULT FALSE,

    created_by TEXT NOT NULL,
    created_at TIMESTAMPTZ NOT NULL,
    updated_at TIMESTAMPTZ NOT NULL,
    version BIGINT NOT NULL
);

Constraint:

ALTER TABLE evidence_file
ADD CONSTRAINT accepted_evidence_integrity_check
CHECK (
  status <> 'ACCEPTED'
  OR (
    sha256 IS NOT NULL
    AND size_bytes IS NOT NULL
    AND scan_decision = 'CLEAN'
    AND object_key IS NOT NULL
  )
);

8. Capstone Configuration

Typed config:

evidence:
  upload:
    max-size-mb: 500
    direct-upload-enabled: true
    presigned-upload-ttl: 5m
  download:
    presigned-download-ttl: 2m
    require-fresh-authorization: true
  scan:
    required: true
    timeout: 60s
  retention:
    default-years-after-case-closure: 7
    legal-hold-enabled: true

Production policy:

scan.required must be true
download.presigned-download-ttl <= 5m
retention.legal-hold-enabled must be true
upload.max-size-mb <= platform maximum

Delivery:

Git -> validation -> GitOps -> ConfigMap -> Spring Boot typed properties -> startup validation

Runtime reload:

  • scan timeout may reload;
  • bucket/prefix/retention policy does not reload silently;
  • production security invariants cannot be disabled dynamically.

9. Capstone Secrets

Secrets:

SecretStrategy
Evidence DB credentialsecret manager + alternating users + rolling restart
Scanner API tokensecret manager + rollout/reload
Audit sink credentialsecret manager
Object storage accessworkload identity preferred
KMS accessIAM/workload identity
TLScert-manager/service mesh or controlled secret volume

Rotation:

create new -> distribute -> canary -> rollout -> prove new use -> revoke old

Consumer proof:

secret_current_version_info
DB audit login user
readiness DB check
dependency_auth_failure_total stable
old credential usage zero

10. Capstone Access Control

Separate operations:

canViewEvidenceMetadata
canDownloadEvidencePayload
canAttachEvidence
canDeleteEvidence
canApplyLegalHold
canExportEvidencePackage

Payload access rules:

Metadata access is not payload access.
Download grant requires fresh authorization.
Presigned URL issuance is audited.
Presigned URL is short-lived.

Cache:

Authorization cache may improve performance,
but critical download action must use fresh or bounded-staleness decision.

11. Capstone Audit Events

Minimum audit matrix:

OperationAudit Event
upload session createEVIDENCE_UPLOAD_SESSION_CREATED
payload receivedEVIDENCE_PAYLOAD_RECEIVED
checksum verifiedEVIDENCE_CHECKSUM_VERIFIED
scan completedEVIDENCE_SCAN_COMPLETED
accepted/rejectedEVIDENCE_FILE_ACCEPTED/REJECTED
download allowed/deniedEVIDENCE_DOWNLOAD_GRANTED/DENIED
legal hold applied/removedEVIDENCE_LEGAL_HOLD_APPLIED/REMOVED
delete requested/blocked/completedEVIDENCE_DELETION_*
config deployedCONFIG_VERSION_DEPLOYED
secret rotatedSECRET_ROTATION_*

Audit event must include:

  • actor;
  • resource;
  • decision;
  • reason code;
  • policy version;
  • timestamp;
  • correlation ID;
  • safe attributes.

12. Capstone Observability

Metrics:

evidence_upload_session_created_total
evidence_upload_completed_total
evidence_scan_pending_age_seconds
evidence_scan_completed_total{decision}
evidence_accepted_total
evidence_download_granted_total
evidence_download_denied_total{reason}
evidence_deletion_blocked_total{reason}
metadata_payload_mismatch_total
audit_outbox_oldest_age_seconds
config_current_version_info
secret_seconds_until_expiry
secret_refresh_failure_total
dependency_auth_failure_total

Alerts:

accepted evidence without checksum > 0
metadata-payload mismatch for accepted evidence > 0
scan pending p95 > 10 minutes
audit outbox oldest age > 60 seconds
secret expires in < 10 minutes and refresh failing
prod config scan.required false
mixed critical config versions beyond rollout window
old DB credential used after rotation window

13. Capstone Failure Model

FailureRequired Behavior
object upload succeeds, DB update failsobject orphan detected/cleaned
DB commit succeeds, event publish failsoutbox retries
scanner downevidence remains not accepted
duplicate scan eventidempotent
legal hold during deletedelete blocked
secret manager downcached credential used within TTL; readiness fails near expiry
config invalidstartup/reload blocked
object storage 503bounded retry/backpressure
audit sink downoutbox persists; high-risk operations may fail closed
pod killed mid-workerqueue redelivery/idempotent processing

14. Capstone Testing Plan

14.1 Unit

[ ] invalid lifecycle transition rejected
[ ] accepted evidence requires clean scan/checksum
[ ] legal hold blocks delete
[ ] secret value toString redacts
[ ] config validation rejects unsafe prod values

14.2 Integration

[ ] direct upload session flow
[ ] object verification flow
[ ] scan worker flow
[ ] download authorization flow
[ ] audit outbox transaction
[ ] secret missing readiness
[ ] config startup validation

14.3 Failure

[ ] storage timeout
[ ] scanner timeout
[ ] duplicate event
[ ] DB deadlock/retry
[ ] audit sink down
[ ] secret rotation bad credential
[ ] ConfigMap drift
[ ] pod kill during processing

14.4 Security

[ ] content type spoof
[ ] path traversal filename
[ ] unauthorized download
[ ] presigned URL not logged
[ ] ConfigMap secret scanner
[ ] broad RBAC forbidden
[ ] actuator restricted

15. Capstone Scoring Rubric

Score from 0 to 5.

Area05
File lifecyclead-hoc uploadexplicit state machine + audit
Storagebucket wrapperdomain metadata + object lifecycle
Integrityno checksumchecksum/object version verified
Securitybasic auth onlyleast privilege + threat model
Configraw env varstyped schema + promotion + drift detection
Secretstatic secretrotation + TTL/readiness + audit
Statehidden statesource of truth + replay/reconciliation
Observabilitygeneric logsinvariant-driven metrics/alerts
Compliancemanual docspolicy-control-evidence-review
Failure testinghappy pathchaos/game day + runbooks

Target for production-grade:

No category below 4.
Critical systems need 5 in security, audit, retention, and recovery.

16. Implementation Roadmap

Phase 1 — Safe Foundation

- typed config
- secret manager integration
- basic metadata model
- object storage adapter
- upload session
- lifecycle state machine
- audit outbox
- checksum verification

Phase 2 — Production Controls

- scanner pipeline
- presigned direct upload/download
- authorization policy integration
- retention/legal hold
- reconciliation jobs
- metrics/logs/traces
- dashboards/alerts

Phase 3 — Operational Maturity

- secret rotation automation
- config promotion platform
- chaos testing
- forensic drill
- access review
- cost controls
- object lock/versioning if required

Phase 4 — Platformization

- reusable file platform library
- config schema registry
- secret inventory and orchestrator
- standardized ADR/runbook templates
- self-service dashboards
- policy-as-code

17. What “Top 1%” Looks Like Here

Not memorizing every API.

A top-tier engineer can:

see that MultipartFile.getOriginalFilename is not authority
see that ConfigMap update does not equal safe runtime reload
see that Kubernetes Secret update does not rotate DB connections
see that object storage key is not domain identity
see that cache can become security state
see that audit log must be durable before destructive operation
see that secret revocation before proof causes outage
see that retention is a domain rule, not only lifecycle policy
see that observability must map to invariants
see that rollback must be designed before rollout

The skill is structural judgment.


After this series, the natural continuations are:

18.1 Platform Engineering for Java Microservices

Focus:

  • golden paths;
  • internal developer platform;
  • service templates;
  • policy-as-code;
  • paved roads;
  • workload identity;
  • service catalog;
  • runtime contracts.

18.2 Advanced Distributed State and Workflow

Focus:

  • workflow engines;
  • saga orchestration/choreography;
  • deterministic replay;
  • temporal models;
  • event sourcing;
  • process audit;
  • compensating actions.

18.3 Secure Software Supply Chain for Java

Focus:

  • SBOM;
  • dependency signing;
  • provenance;
  • SLSA;
  • artifact promotion;
  • image signing;
  • vulnerability management;
  • runtime admission.

18.4 Production Data Governance Engineering

Focus:

  • data classification;
  • retention;
  • privacy;
  • lineage;
  • access review;
  • audit evidence;
  • deletion workflows;
  • legal hold.

18.5 Resilience Engineering and Game Days

Focus:

  • chaos engineering;
  • SLO/error budget;
  • incident command;
  • failure injection;
  • recovery drills;
  • socio-technical reliability.

18.6 Advanced Cloud Storage Architecture

Focus:

  • multi-region object storage;
  • replication;
  • object lock;
  • archival retrieval;
  • storage cost modeling;
  • CDN/private content;
  • data residency.

19. Final Series Summary

The core pattern across this entire series is:

Separate responsibility.
Name the artifact.
Own the lifecycle.
Validate the boundary.
Preserve the invariant.
Emit evidence.
Observe stress.
Reconcile drift.
Practice failure.

Applied to files:

bytes + metadata + lifecycle + policy + audit

Applied to state:

truth + ownership + consistency + reconstruction

Applied to config:

schema + provenance + validation + promotion + rollback

Applied to secrets:

capability + least privilege + TTL + rotation + proof

Applied to production:

invariant + observability + runbook + game day + evidence

20. Final Checklist

Before claiming a Java microservice handles file/state/config/secret production-grade, verify:

[ ] File identity independent of storage key
[ ] Metadata and payload consistency strategy exists
[ ] Accepted files require checksum and trust decision
[ ] Upload/download authorization separated
[ ] Presigned URLs short-lived and not logged
[ ] State source of truth explicit
[ ] Critical state not stored only in local disk/memory
[ ] Config typed, validated, versioned, and governed
[ ] Runtime reload only where safe
[ ] Secrets stored in secret manager or encrypted GitOps path
[ ] Secret rotation strategy tested
[ ] Least privilege IAM/RBAC applied
[ ] Sensitive data redaction tested
[ ] Audit events cover material decisions
[ ] Audit pipeline durable and monitored
[ ] Retention/legal hold enforced before delete
[ ] Reconciliation jobs deployed
[ ] Dashboards and alerts map to invariants
[ ] Failure/chaos tests run
[ ] Runbooks exist and are current
[ ] ADRs document major decisions

21. Closing Mental Model

A weak system says:

We uploaded the file.
We set the config.
We stored the secret.
We have logs.

A strong system says:

We know who owns the file.
We know its lifecycle state.
We know its checksum.
We know who can access it.
We know which config version influenced behavior.
We know which secret version was used.
We know how it fails.
We know how it recovers.
We know how to prove what happened.

That is the difference between code that works and a system that can be trusted.

This series is now complete.


References

Lesson Recap

You just completed lesson 70 in final stretch. Use the series map if you want to review the broader track, or continue directly into the next lesson while the context is still warm.

Continue The Track

Keep the momentum while the lesson is still fresh. Move backward for review or continue forward into the next concept.