Dalam rekayasa perangkat lunak modern, arsitektur sistem dan pola desain (design patterns) adalah pilar utama yang menentukan seberapa tangguh, adaptif, dan skalabel sistem Anda terhadap perubahan bisnis. Tanpa pemahaman taksonomi yang terstruktur, insinyur sering kali terjebak dalam perangkap over-engineering atau sebaliknya, membangun sistem terkopel erat (tightly coupled) yang sulit dimigrasi.
Cetak biru taksonomi visual di bawah memetakan 380+ pola arsitektur & desain lintas 3 pilar utama: System Architecture Styles, Application Architecture, dan Design Patterns (GoF & Beyond), yang terbagi dalam era Classic (🔵), Modern (🟢), dan Frontier/Research (🔴).
Kode Era Kategori: 🔵 Classic | 🟢 Modern | 🔴 Research/Frontier
1. System Architecture Styles
1.1 Monolithic
| Pola | Era | Penggunaan | Keunggulan | Tantangan |
|---|---|---|---|---|
| Layered (N-Tier) | 🔵 Classic | Enterprise apps, ERP, legacy web | Simple, easy to develop | Tight coupling, scaling bottleneck |
| Modular Monolith | 🟢 Modern | Mid-size apps, team-scale systems | Deployment simplicity + modularity | Shared DB still couples |
| Single-Tier | 🔵 Classic | Desktop apps, offline tools | No network latency | Not distributable |
| Two-Tier (Client-Server) | 🔵 Classic | LAN apps, legacy client-server | Simple | Doesn't scale well |
| Three-Tier | 🔵 Classic | Web apps, CRUD systems | Clear separation | Can be rigid |
Deskripsi:
- Layered (N-Tier): Arsitektur berlapis horizontal — presentation → business logic → data access. Paling umum di enterprise software tradisional.
- Modular Monolith: Monolith terstruktur dengan modul terisolasi kuat; dapat dipisah menjadi microservice jika perlu.
- Single-Tier: Semua komponen (UI, logic, data) dalam satu proses atau mesin.
- Two-Tier: Client memanggil server langsung; server mengelola data.
- Three-Tier: Presentation - Application - Data tiga layer terpisah; standar web tradisional.
1.2 Service-Based
| Pola | Era | Penggunaan | Keunggulan | Tantangan |
|---|---|---|---|---|
| SOA (Service-Oriented Architecture) | 🔵 Classic | Enterprise integration, B2B | Reusability | ESB is complex & centralized |
| Microservices | 🟢 Modern | Netflix, Uber, Amazon — scalable systems | Independent scaling & deployment | Operational complexity |
| Micro-Frontend | 🟢 Modern | Large-scale web UI teams | Team autonomy | Integration complexity |
| Nanoservices | 🔴 Research | FaaS, AWS Lambda extreme decomposition | Maximum granularity | Coordination overhead extreme |
| Miniservices | 🟢 Modern | Pragmatic microservice adoption | Balanced tradeoffs | Still needs service mesh |
| Backend for Frontend (BFF) | 🟢 Modern | Mobile/web API aggregation | Optimized per client | Code duplication risk |
| API Gateway | 🟢 Modern | All microservice deployments | Centralized cross-cutting concerns | Single point of failure risk |
Deskripsi:
- SOA: Layanan terhubung via ESB (Enterprise Service Bus). Standar enterprise 2000-an.
- Microservices: Aplikasi dipecah menjadi layanan kecil independen yang bisa di-deploy dan di-scale secara terpisah.
- Micro-Frontend: Arsitektur frontend memecah UI menjadi modul independen yang dikembangkan tim berbeda.
- Nanoservices: Dekomposisi ekstrem di luar microservice; setiap fungsi menjadi layanan tersendiri.
- Miniservices: Pertengahan antara monolith dan microservice; kelompok fungsi terkait dalam satu service.
- BFF: Setiap jenis klien (mobile, web, TV) punya backend sendiri yang disesuaikan kebutuhannya.
- API Gateway: Single entry point untuk semua klien; routing, auth, rate limiting, logging terpusat.
1.3 Event-Driven
| Pola | Era | Penggunaan | Keunggulan | Tantangan |
|---|---|---|---|---|
| Event-Driven Architecture (EDA) | 🟢 Modern | Real-time systems, IoT, finance | High decoupling | Difficult to trace/debug |
| Message Queue Architecture | 🔵 Classic | Background jobs, async processing | Decouples producers & consumers | Message ordering challenges |
| Publish-Subscribe (Pub/Sub) | 🔵 Classic | Notification, event streaming | Fan-out easy | No guaranteed delivery order |
| Event Streaming | 🟢 Modern | Kafka, Kinesis — analytics pipeline | Replayable, audit log built-in | Storage grows |
| Choreography | 🟢 Modern | Saga pattern, distributed workflows | No central bottleneck | Hard to track overall flow |
| Orchestration | 🟢 Modern | Saga via orchestrator, BPMN | Clear flow visibility | Central coordinator = bottleneck |
Deskripsi:
- EDA: Komponen berkomunikasi via events; publisher tidak tahu consumer. Decoupled & async.
- Message Queue: Pesan dikirim ke queue; consumer memprosesnya async. Contoh: RabbitMQ, SQS.
- Pub/Sub: Publisher kirim event ke topic; semua subscriber yang tertarik menerima.
- Event Streaming: Event disimpan dalam log terurut yang bisa di-replay; bukan hanya kirim-terima.
- Choreography: Setiap service mendengarkan event dan bereaksi; tidak ada pusat koordinasi.
- Orchestration: Orchestrator pusat yang memerintahkan urutan langkah; lebih mudah dilacak.
1.4 Distributed & Cloud-Native
| Pola | Era | Penggunaan | Keunggulan | Tantangan |
|---|---|---|---|---|
| Cloud-Native | 🟢 Modern | Kubernetes, AWS, GCP deployments | Elastic scaling | Cloud vendor lock-in risk |
| Serverless / FaaS | 🟢 Modern | AWS Lambda, Cloud Functions, event handlers | Zero ops, auto-scale | Cold start, stateless only |
| Service Mesh | 🟢 Modern | Istio, Linkerd — microservice comms | Consistent policy enforcement | Extra complexity layer |
| Cell-Based Architecture | 🔴 Research | Hyper-scale SaaS, AWS internal | Blast radius containment | Complex routing |
| Multi-Cloud Architecture | 🟢 Modern | Enterprise avoiding vendor lock-in | Resilience | Management complexity |
| Edge Computing | 🟢 Modern | CDN, IoT, AR/VR, autonomous vehicles | Ultra-low latency | Heterogeneous environment |
| Fog Computing | 🔴 Research | Industrial IoT, smart city | Reduced cloud bandwidth | New infrastructure layer |
| Peer-to-Peer (P2P) | 🔵 Classic | BitTorrent, blockchain, WebRTC | No central point of failure | Discovery & coordination hard |
Deskripsi:
- Cloud-Native: Sistem dirancang khusus untuk cloud: containerized, orchestrated, elastic, observable.
- Serverless/FaaS: Developer menulis fungsi; infrastruktur dikelola cloud provider. Pay per invocation.
- Service Mesh: Layer infrastruktur yang mengelola komunikasi service-to-service: mTLS, retries, observability.
- Cell-Based: Sistem dibagi menjadi sel-sel isolasi yang operasi independen; gagal satu tidak merembet.
- Edge Computing: Komputasi dilakukan di edge (dekat user/device), bukan di central cloud.
- Fog Computing: Layer antara edge devices dan cloud; agregasi & preprocessing data sebelum ke cloud.
- P2P: Node berkomunikasi langsung tanpa server pusat; setiap node bisa jadi client & server.
1.5 Data-Intensive
| Pola | Era | Penggunaan | Keunggulan | Tantangan |
|---|---|---|---|---|
| Lambda Architecture | 🟢 Modern | Big data: Hadoop + Spark + real-time | Balances accuracy & speed | Code duplication across layers |
| Kappa Architecture | 🟢 Modern | Kafka-based unified stream processing | Simpler than Lambda | Stream reprocessing harder |
| Data Mesh | 🟢 Modern | Enterprise data platform decentralization | Domain ownership | Governance challenges |
| Data Fabric | 🔴 Research | Unified enterprise data access layer | Unified data access | Requires mature metadata layer |
| Data Lakehouse | 🟢 Modern | Databricks, Delta Lake, Iceberg | Flexibility + reliability | Still maturing |
| CQRS | 🟢 Modern | High-performance read/write workloads | Independent read/write scaling | Eventual consistency complexity |
| Event Sourcing | 🟢 Modern | Audit-heavy systems, banking, DDD | Full audit trail, temporal queries | Complex to implement |
Deskripsi:
- Lambda Architecture: Dua jalur paralel: batch layer (akurat, lambat) + speed layer (cepat, approximate) → serving layer.
- Kappa Architecture: Menyederhanakan Lambda dengan satu jalur streaming saja; batch adalah special case stream.
- Data Mesh: Data dikelola oleh domain team yang memilikinya sebagai produk data mandiri.
- Data Fabric: Layer metadata aktif yang menghubungkan semua data silo secara otomatis dengan AI.
- Data Lakehouse: Gabungan Data Lake (raw storage) + Data Warehouse (schema, ACID) dalam satu platform.
- CQRS: Memisahkan model untuk write (command) dan read (query); optimasi independen.
- Event Sourcing: State disimpan sebagai urutan event, bukan state terakhir; event adalah source of truth.
2. Application Architecture Patterns
2.1 UI / Presentation Patterns
| Pola | Era | Penggunaan | Keunggulan | Tantangan |
|---|---|---|---|---|
| MVC (Model-View-Controller) | 🔵 Classic | Rails, Spring MVC, ASP.NET, Django | Clear separation of concerns | Controller bloat in complex apps |
| MVP (Model-View-Presenter) | 🔵 Classic | Android (legacy), WinForms | Testable (View is passive) | Many interface definitions |
| MVVM (Model-View-ViewModel) | 🟢 Modern | WPF, Angular, Vue, SwiftUI | Two-way data binding | Overkill for simple UIs |
| MVI (Model-View-Intent) | 🟢 Modern | Android (Compose), Redux-style apps | Predictable state | Verbose for simple cases |
| MVU (Model-View-Update) | 🟢 Modern | Elm, Elmish (F#), Swift TCA | Pure functional, easily testable | Learning curve |
| Flux | 🟢 Modern | Facebook web apps, precursor to Redux | Predictable updates | Verbose boilerplate |
| Redux / Elm Architecture | 🟢 Modern | React apps, global state management | Time-travel debugging | Boilerplate heavy |
| Presentation-Domain-Data Layering | 🔵 Classic | Most enterprise apps | Foundational layering | Can blur in practice |
| PAC (Presentation Abstraction Control) | 🔵 Classic | Complex UI systems research | Hierarchical decomposition | Complex, rarely used |
| VIPER | 🟢 Modern | iOS clean architecture | Testable, SRP adherent | Very verbose |
| Clean Architecture (Uncle Bob) | 🟢 Modern | Domain-driven apps, testable systems | Framework-independent | Requires discipline |
| Hexagonal (Ports & Adapters) | 🟢 Modern | DDD, testable backend systems | Core completely isolated | Many adapter classes |
| Onion Architecture | 🟢 Modern | DDD enterprise applications | Domain purity | Conceptually similar to Hexagonal |
Deskripsi:
- MVC: Model menyimpan data, View menampilkan UI, Controller menghubungkan keduanya.
- MVP: Presenter menggantikan Controller; View pasif, semua logic di Presenter.
- MVVM: ViewModel mengekspos data dan command; View binding langsung ke ViewModel.
- MVI: Unidirectional data flow: Intent → Model → View; single state management.
- MVU: Elm architecture: model adalah state, update adalah pure function, view adalah render.
- Flux: Unidirectional data flow: Action → Dispatcher → Store → View.
- Redux: Single immutable store, pure reducer functions, actions describe intent.
- Clean Architecture: Concentric circles: Entities → Use Cases → Interface Adapters → Frameworks. Dependencies inward only.
- Hexagonal: Core domain isolated; komunikasi via port (interface) dan adapter (implementasi).
- Onion: Jeffrey Palermo: lapisan konsentris dengan domain di tengah.
2.2 API & Communication Patterns
| Pola | Era | Penggunaan | Keunggulan | Tantangan |
|---|---|---|---|---|
| REST | 🔵 Classic | Web APIs everywhere | Simple, universal, cacheable | Over/under-fetching |
| GraphQL | 🟢 Modern | Facebook, GitHub, Shopify APIs | Eliminates over/under-fetching | Caching complex, N+1 problem |
| gRPC | 🟢 Modern | Microservice internal comms, Google APIs | Fast, strongly typed | Not human-readable |
| WebSocket | 🟢 Modern | Chat, live dashboard, gaming | Real-time bidirectional | Stateful, scaling harder |
| Server-Sent Events (SSE) | 🟢 Modern | Live feeds, progress streaming | Simple, HTTP-compatible | One-directional only |
| Webhook | 🟢 Modern | GitHub events, payment callbacks | Push-based, decoupled | No guaranteed delivery |
| SOAP | 🔵 Classic | Enterprise B2B, banking legacy | Strong contract, enterprise standard | Verbose, complex |
| HATEOAS | 🔵 Classic | Mature REST APIs | Discoverable API | Complex client implementation |
| JSON:API | 🟢 Modern | Standardized REST APIs | Consistent format | Verbose |
| tRPC | 🟢 Modern | TypeScript full-stack apps | End-to-end type safety | TypeScript only |
| OpenAPI / Swagger | 🟢 Modern | API documentation & codegen | Ecosystem tooling | Documentation drift |
Deskripsi:
- REST: Resource-based HTTP API menggunakan verbs (GET, POST, PUT, DELETE) dan stateless.
- GraphQL: Client menentukan shape data yang dibutuhkan; single endpoint untuk semua query.
- gRPC: RPC framework menggunakan Protocol Buffers; strongly typed, streaming, multi-language.
- WebSocket: Full-duplex persistent connection antara client dan server.
- SSE: Server push one-way ke client via HTTP; simpler dari WebSocket untuk uni-directional.
- Webhook: HTTP callback: server kirim POST ke URL klien saat event terjadi.
- SOAP: XML-based protocol dengan WSDL contract; strict typing.
- tRPC: Type-safe API tanpa schema: langsung call server function dari client dengan type inference.
3. Design Patterns (GoF & Beyond)
3.1 Creational Patterns
| Pola | Era | Penggunaan | Keunggulan | Tantangan |
|---|---|---|---|---|
| Singleton | 🔵 Classic | Config managers, logging, connection pools | Controlled access to single instance | Global state, hard to test |
| Factory Method | 🔵 Classic | Frameworks, plugin systems | Open/closed principle | Can proliferate subclasses |
| Abstract Factory | 🔵 Classic | UI toolkit families, cross-platform | Product family consistency | Adding products is hard |
| Builder | 🔵 Classic | Complex object construction, query builders | Controlled construction | Many builder classes needed |
| Prototype | 🔵 Classic | Game objects, object cloning | Avoids class hierarchy | Deep copy complexity |
| Object Pool | 🔵 Classic | DB connections, thread pools | Performance, resource management | Pool management complexity |
| Dependency Injection | 🟢 Modern | Spring, Angular, .NET Core — everywhere | Testable, loose coupling | Config complexity |
| Service Locator | 🔵 Classic | Game engines, some DI alternatives | Simple lookup | Hides dependencies |
Deskripsi:
- Singleton: Memastikan hanya satu instance dari sebuah class yang dibuat.
- Factory Method: Interface untuk membuat objek, tapi subclass menentukan class yang diinstansiasi.
- Abstract Factory: Interface untuk membuat keluarga objek terkait tanpa menentukan class konkret.
- Builder: Membangun objek kompleks step by step; pisahkan konstruksi dari representasi.
- Prototype: Membuat objek baru dengan meng-clone instance yang sudah ada.
- Object Pool: Reuse pre-created objects dari pool daripada membuat/menghapus berulang.
- Dependency Injection: Dependencies di-inject dari luar, bukan dibuat di dalam class; inversion of control.
- Service Locator: Registry pusat yang menyediakan service; anti-pattern jika digunakan sembarangan.
3.2 Structural Patterns
| Pola | Era | Penggunaan | Keunggulan | Tantangan |
|---|---|---|---|---|
| Adapter | 🔵 Classic | Legacy integration, library wrapping | Enables incompatible interfaces to work | Extra complexity |
| Bridge | 🔵 Classic | Platform-specific implementations | Decouples abstraction from implementation | Increases complexity |
| Composite | 🔵 Classic | File systems, UI component trees, DOM | Uniform interface for tree structures | Overly general |
| Decorator | 🔵 Classic | Java I/O streams, middleware chains | Flexible alternative to subclassing | Many small objects |
| Facade | 🔵 Classic | Library APIs, SDK simplification | Simplifies usage | Can become god object |
| Flyweight | 🔵 Classic | Game engines (many similar objects), fonts | Reduces memory usage | Complexity increases |
| Proxy | 🔵 Classic | Lazy loading, caching, access control | Controls access | Response time may increase |
| Module Pattern | 🔵 Classic | JavaScript before ES modules | Encapsulation in JS | Obsolete with ES modules |
Deskripsi:
- Adapter: Converts interface sebuah class ke interface yang klien harapkan.
- Bridge: Memisahkan abstraksi dari implementasi agar keduanya bisa berubah independen.
- Composite: Menyusun objek dalam struktur pohon; treat individual objects dan compositions seragam.
- Decorator: Menambah behavior ke objek secara dinamis dengan membungkusnya.
- Facade: Menyediakan interface sederhana untuk subsystem yang kompleks.
- Flyweight: Berbagi state umum antar banyak objek kecil untuk menghemat memory.
- Proxy: Surrogate yang mengontrol akses ke objek lain.
3.3 Behavioral Patterns
| Pola | Era | Penggunaan | Keunggulan | Tantangan |
|---|---|---|---|---|
| Chain of Responsibility | 🔵 Classic | Middleware, event handling, logging | Decouples sender and receiver | No guarantee of handling |
| Command | 🔵 Classic | Undo/redo, queuing actions, macros | Undo support | Many command classes |
| Iterator | 🔵 Classic | Collections, database cursor | Uniform traversal | Overkill for simple collections |
| Mediator | 🔵 Classic | Chat rooms, air traffic control, UI dialogs | Reduces dependencies | Mediator becomes complex |
| Memento | 🔵 Classic | Undo/redo, game save state | Undo without breaking encapsulation | Memory intensive |
| Observer | 🔵 Classic | Event systems, MVC, reactive programming | Loose coupling | Unexpected updates, memory leaks |
| State | 🔵 Classic | Workflow engines, vending machines, parsers | Eliminates conditionals | Many state classes |
| Strategy | 🔵 Classic | Sorting algorithms, payment methods | Open/closed principle | Client aware of strategies |
| Template Method | 🔵 Classic | Frameworks (hooks), data processing pipelines | Code reuse | Limited flexibility |
| Visitor | 🔵 Classic | Compilers, static analysis | Open/closed principle | Breaks encapsulation |
| Interpreter | 🔵 Classic | SQL parsers, regex engines, scripting | Easy to change grammar | Complex for large grammars |
| Null Object | 🔵 Classic | Avoiding null checks everywhere | Eliminates null checks | Can hide errors |
| Specification | 🟢 Modern | Business rules, query building, DDD | Combinable business rules | Can be overengineered |
Deskripsi:
- Chain of Responsibility: Meneruskan request melalui rantai handler; setiap handler memutuskan proses atau teruskan.
- Command: Encapsulasi request sebagai objek; mendukung undo, queue, dan log.
- Iterator: Provides cara sequential access elemen koleksi tanpa expose representasinya.
- Mediator: Objek yang mengendalikan interaksi antar objek untuk mengurangi coupling.
- Memento: Capture dan externalize state internal objek agar bisa restore nanti.
- Observer: One-to-many dependency: saat object berubah, semua dependent diberi notifikasi.
- State: Mengubah behavior objek saat state-nya berubah; seperti finite state machine.
- Strategy: Mendefinisikan keluarga algoritma, enkapsulasi masing-masing, dan buat mereka interchangeable.
- Template Method: Mendefinisikan skeleton algoritma; subclass mengisi langkah tertentu.
- Visitor: Operasi baru pada elemen objek tanpa mengubah class-nya.
- Specification: Encapsulasi aturan bisnis dalam objek yang bisa dikombinasikan (AND, OR, NOT).
Berikut adalah Matriks Klasifikasi & Peta Hubungan GoF Design Patterns yang membagi kategori Creational, Structural, dan Behavioral lengkap dengan cetak biru arsitektur pola populer (Builder, Adapter, Decorator, dan Observer):
3.4 Concurrency Patterns
| Pola | Era | Penggunaan | Keunggulan | Tantangan |
|---|---|---|---|---|
| Active Object | 🔵 Classic | Async request handling | Decoupled threading | Complex setup |
| Monitor Object | 🔵 Classic | Thread-safe objects, Java synchronized | Mutex via encapsulation | Potential deadlock |
| Half-Sync/Half-Async | 🔵 Classic | Network servers, thread pool servers | Simplifies concurrency | Synchronization overhead |
| Thread Pool | 🔵 Classic | Web servers, task executors | Resource efficient | Pool sizing is tricky |
| Reactor | 🔵 Classic | Nginx, Node.js event loop, Netty | High concurrency, low overhead | CPU-bound tasks block |
| Proactor | 🔵 Classic | Windows IOCP, async I/O | True async I/O | Complex implementation |
| Scheduler | 🔵 Classic | OS, task queues | Controlled access | Potential bottleneck |
| Actor Model | 🟢 Modern | Erlang, Akka, Orleans — distributed systems | Naturally concurrent | Debugging message flows |
Deskripsi:
- Active Object: Memisahkan method execution dari invocation dengan scheduler terpisah.
- Monitor Object: Synchronisasi concurrent method execution untuk mengontrol akses.
- Half-Sync/Half-Async: Memisahkan synchronous processing (I/O) dari async dengan queue.
- Thread Pool: Pool thread yang siap pakai; task diqueue dan dikerjakan thread tersedia.
- Reactor: Event loop single-thread menangani banyak connections via non-blocking I/O.
- Proactor: Seperti Reactor tapi completion handler dipanggil setelah operasi selesai.
- Actor Model: Unit komputasi independen (actor) berkomunikasi via message; no shared state.
4. Enterprise Integration Patterns
4.1 Messaging Patterns
| Pola | Era | Penggunaan | Keunggulan | Tantangan |
|---|---|---|---|---|
| Message Channel | 🔵 Classic | All messaging systems | Decoupling | Asynchrony adds complexity |
| Message Router | 🔵 Classic | ESB, conditional routing | Dynamic routing | Routing logic complexity |
| Message Translator | 🔵 Classic | Integration, ETL | Enables heterogeneous systems | Transformation logic maintenance |
| Message Filter | 🔵 Classic | Event filtering, noise reduction | Reduces processing load | Lost messages risk |
| Content-Based Router | 🔵 Classic | Order routing, multicast | Smart routing | Complex routing rules |
| Splitter | 🔵 Classic | Batch processing | Parallel processing | Correlation needed |
| Aggregator | 🔵 Classic | Combine partial results | Combines partial results | Timeout handling needed |
| Resequencer | 🔵 Classic | Out-of-order message fixing | Order guarantee | Buffering required |
| Scatter-Gather | 🔵 Classic | Parallel queries, price comparison | Parallel processing | Slowest response determines latency |
| Process Manager | 🔵 Classic | Multi-step business workflows | Complex flow management | Stateful, complex |
| Saga Pattern | 🟢 Modern | Distributed transactions, microservices | No distributed lock needed | Compensating transactions complex |
| Outbox Pattern | 🟢 Modern | Reliable event publishing with DB | At-least-once delivery guarantee | CDC or polling needed |
| Inbox Pattern | 🟢 Modern | Idempotent message consumption | Idempotency | Extra storage |
| Dead Letter Queue | 🔵 Classic | Failed message handling | Prevents message loss | DLQ needs monitoring |
| Claim Check | 🔵 Classic | Large message handling | Reduces message size | Extra storage call |
Deskripsi:
- Message Channel: Pipe yang menghubungkan sender dan receiver; basis semua messaging.
- Message Router: Memilih channel tujuan berdasarkan konten atau kondisi message.
- Message Translator: Mengubah format message dari satu sistem ke sistem lain.
- Splitter: Memecah satu message menjadi beberapa message individual.
- Aggregator: Mengumpulkan beberapa message terkait menjadi satu message.
- Scatter-Gather: Kirim request ke beberapa penerima, kumpulkan semua balasan.
- Saga: Urutan transaksi lokal dengan kompensasi jika ada yang gagal; menggantikan 2PC.
- Outbox: Event disimpan di DB table (outbox) dalam transaksi yang sama; CDC atau polling untuk kirim.
- Inbox: Consumer catat message yang sudah diproses untuk hindari duplikasi.
- Dead Letter Queue: Queue untuk message yang gagal diproses; untuk debugging dan reprocessing.
- Claim Check: Store payload di external storage; kirim hanya reference. Mengurangi message size.
4.2 Data Integration Patterns
| Pola | Era | Penggunaan | Keunggulan | Tantangan |
|---|---|---|---|---|
| ETL (Extract-Transform-Load) | 🔵 Classic | Data warehouse loading | Standard approach | Batch latency |
| ELT (Extract-Load-Transform) | 🟢 Modern | Cloud data warehouse (BigQuery, Snowflake) | Leverage warehouse compute | Raw data storage costs |
| CDC (Change Data Capture) | 🟢 Modern | Debezium, real-time sync | Real-time, low source impact | Binlog parsing complexity |
| Data Replication | 🔵 Classic | DR, read replicas | Redundancy & read scaling | Replication lag |
| Federated Query | 🟢 Modern | Query across multiple databases | No data movement | Performance varies |
4.3 Reliability Patterns
| Pola | Era | Penggunaan | Keunggulan | Tantangan |
|---|---|---|---|---|
| Circuit Breaker | 🟢 Modern | Microservice resilience | Prevents cascade failures | Tuning thresholds is tricky |
| Bulkhead | 🟢 Modern | Isolation in microservices | Fault isolation | Resource fragmentation |
| Retry Pattern | 🔵 Classic | Transient failure handling | Handles transient failures | Retry storm risk |
| Timeout Pattern | 🔵 Classic | All network calls | Prevents hanging | Timeout value is tricky |
| Fallback Pattern | 🟢 Modern | Graceful degradation | Graceful degradation | Stale data risk |
| Rate Limiting | 🟢 Modern | API throttling, DDoS protection | Protects downstream | Legitimate traffic affected |
| Throttling | 🟢 Modern | Resource protection | Smooth load | Increased latency |
| Health Endpoint | 🟢 Modern | Kubernetes liveness/readiness probes | Automated health checking | Endpoint security needed |
| Sidecar Pattern | 🟢 Modern | Istio, Envoy proxy, logging agents | Separation of concerns | Distributed system complexity |
| Ambassador Pattern | 🟢 Modern | Proxy for legacy apps | Offloads connectivity concerns | Extra hop |
| Anti-Corruption Layer | 🟢 Modern | DDD legacy integration | Domain model purity | Maintenance overhead |
| Strangler Fig | 🟢 Modern | Legacy modernization | Low-risk incremental migration | Dual maintenance period |
Deskripsi:
- Circuit Breaker: Memutus circuit ke service yang gagal; fallback behavior selama open.
- Bulkhead: Isolasi resource per service/feature agar gagalnya satu tidak mengambil semua.
- Retry: Retry request yang gagal dengan exponential backoff dan jitter.
- Sidecar: Helper container yang berjalan di samping main container; shared lifecycle.
- Anti-Corruption Layer: Layer translasi antara domain model baru dan sistem legacy.
- Strangler Fig: Migrasi bertahap: bungkus legacy, pindahkan fitur satu per satu hingga legacy bisa dimatikan.
Berikut adalah Cetak Biru Enterprise Integration Patterns (EIP) yang memetakan mekanisme penanganan kegagalan dinamis Circuit Breaker State Machine dan orkestrasi perutean data Content-Based Router:
5. Cloud & DevOps Patterns
5.1 Deployment & Release Patterns
| Pola | Era | Penggunaan | Keunggulan | Tantangan |
|---|---|---|---|---|
| Blue-Green Deployment | 🟢 Modern | Zero-downtime releases | Zero downtime, instant rollback | Double infrastructure cost |
| Canary Deployment | 🟢 Modern | Progressive rollout | Risk mitigation | Complex traffic routing |
| Rolling Deployment | 🟢 Modern | Kubernetes default rollout | No extra infrastructure | Slower rollout |
| Feature Flags / Toggles | 🟢 Modern | Trunk-based development, A/B testing | Decouple deploy from release | Flag debt accumulates |
| Shadow Deployment | 🟢 Modern | Dark launch testing | Real traffic testing | Double processing |
| A/B Testing Architecture | 🟢 Modern | Product experimentation | Data-driven decisions | Statistical significance takes time |
| GitOps | 🟢 Modern | Kubernetes, ArgoCD, Flux | Audit trail, rollback via revert | Git workflow discipline required |
| Infrastructure as Code (IaC) | 🟢 Modern | Terraform, Pulumi, CloudFormation | Reproducible environments | Learning curve |
Deskripsi:
- Blue-Green: Dua environment identik (blue=live, green=new); traffic pindah ke green setelah ready.
- Canary: Rilis ke subset kecil user dulu; monitor, lalu expand bertahap.
- Feature Flags: Fitur dikontrol via flag di runtime; deploy terpisah dari release.
- GitOps: Git sebagai single source of truth untuk infrastruktur; perubahan via PR.
- IaC: Infrastruktur didefinisikan sebagai kode; versi kontrol, review, dan reproducible.
5.2 Observability Patterns
| Pola | Era | Penggunaan | Keunggulan | Tantangan |
|---|---|---|---|---|
| Three Pillars of Observability | 🟢 Modern | All distributed systems | Comprehensive visibility | Cost and tooling overhead |
| Distributed Tracing | 🟢 Modern | Jaeger, Zipkin, Tempo | End-to-end request visibility | Sampling vs completeness tradeoff |
| Log Aggregation | 🟢 Modern | ELK Stack, Loki | Centralized troubleshooting | Storage costs |
| Metrics Aggregation | 🟢 Modern | Prometheus, Grafana | Performance monitoring | Cardinality explosion |
| Event Correlation | 🟢 Modern | APM, security SIEM | Root cause analysis | Complex correlation rules |
| Synthetic Monitoring | 🟢 Modern | Pingdom, Datadog synthetics | Proactive issue detection | Not real user behavior |
| Real User Monitoring (RUM) | 🟢 Modern | Core Web Vitals, web performance | Real user experience data | Privacy considerations |
5.3 Security Patterns
| Pola | Era | Penggunaan | Keunggulan | Tantangan |
|---|---|---|---|---|
| Zero Trust Architecture | 🟢 Modern | Modern enterprise security | Reduced attack surface | Latency from verification |
| OAuth 2.0 / OIDC | 🟢 Modern | Authorization and SSO | Industry standard | Complex flows |
| mTLS (Mutual TLS) | 🟢 Modern | Service mesh, zero trust | Bidirectional auth | Certificate management |
| API Key Pattern | 🔵 Classic | Public APIs, developer access | Simple to implement | Not user-level auth |
| Vault Pattern | 🟢 Modern | HashiCorp Vault, secret management | Centralized secrets | Vault becomes critical dependency |
| RBAC (Role-Based Access Control) | 🔵 Classic | Most authorization systems | Manageable at scale | Role explosion |
| ABAC (Attribute-Based Access Control) | 🟢 Modern | Fine-grained authorization | Very fine-grained | Complex policy management |
| PBAC (Policy-Based Access Control) | 🟢 Modern | Zanzibar (Google), Oso, Casbin | Centralized policy | Policy debugging hard |
Deskripsi:
- Zero Trust: Model keamanan asersi eksplisit: verifikasi identitas, otorisasi, enkripsi mTLS pada setiap langkah.
- Canary Deployment: Strategi rilis perangkat lunak bertahap dengan membagi persentase kecil lalu lintas ke versi baru.
- Blue-Green Deployment: Strategi rilis bebas downtime dengan beralih cepat antara dua lingkungan produksi independen.
- Distributed Tracing: Pelacakan span eksekusi terdistribusi antar microservices untuk analisis latensi.
Berikut adalah Cetak Biru Cloud & DevOps Patterns yang memetakan strategi perutean lalu lintas rilis aplikasi (Canary vs Blue-Green) serta analisis latensi eksekusi terdistribusi (Distributed Tracing Span Timings):
6. Domain-Driven Design (DDD)
6.1 Strategic Patterns
| Pola | Era | Penggunaan | Keunggulan | Tantangan |
|---|---|---|---|---|
| Bounded Context | 🟢 Modern | Microservice boundary definition | Clear domain boundaries | Context mapping needed |
| Ubiquitous Language | 🟢 Modern | Team communication, code naming | Shared understanding | Effort to establish |
| Context Map | 🟢 Modern | Large system integration design | Explicit integration strategy | Maintenance as system evolves |
| Shared Kernel | 🟢 Modern | Closely related bounded contexts | Code sharing | Tight coupling |
| Customer-Supplier | 🟢 Modern | API design, team dependencies | Clear dependency | Upstream may prioritize own needs |
| Conformist | 🟢 Modern | When you can't change upstream | Simple | Suboptimal model |
| Open Host Service | 🟢 Modern | Published API design | Standard integration | Breaking changes affect all |
| Published Language | 🟢 Modern | Industry standards integration | Vendor neutral | Schema evolution hard |
Deskripsi:
- Bounded Context: Batas eksplisit di mana model domain tertentu berlaku; setiap context punya ubiquitous language sendiri.
- Ubiquitous Language: Bahasa umum yang digunakan developer dan domain expert; kata yang sama di code dan percakapan.
- Context Map: Peta hubungan antar bounded context: Upstream/Downstream, Shared Kernel, ACL, dll.
- Shared Kernel: Subset model yang dishared antar dua context; perubahan koordinasi diperlukan.
- Conformist: Downstream mengikuti model upstream tanpa modifikasi.
- Open Host Service: Context mempublikasikan protocol untuk integrasi yang mudah diakses banyak pihak.
6.2 Tactical Patterns
| Pola | Era | Penggunaan | Keunggulan | Tantangan |
|---|---|---|---|---|
| Entity | 🟢 Modern | Business objects with identity | Clear identity concept | Identity management overhead |
| Value Object | 🟢 Modern | Money, addresses, coordinates | Immutable, side-effect free | Must replace to change |
| Aggregate | 🟢 Modern | Consistency boundary in domain | Consistency guarantee | Aggregate size tradeoffs |
| Domain Event | 🟢 Modern | Decoupled domain communication | Decoupled communication | Eventual consistency |
| Repository | 🟢 Modern | Data access abstraction | Domain isolation from DB | Can leak DB concerns |
| Domain Service | 🟢 Modern | Cross-entity business logic | Clean placement of cross-entity logic | Can become anemic domain model |
| Application Service | 🟢 Modern | Use case orchestration | Clear use case boundary | Thin vs orchestration balance |
| Factory (DDD) | 🟢 Modern | Complex aggregate creation | Clean creation logic | Extra class |
| Specification Pattern (DDD) | 🟢 Modern | Business rule specification | Reusable business rules | Can be over-used |
Deskripsi:
- Entity: Objek dengan identity unik yang persists sepanjang waktu; identity bukan nilai.
- Value Object: Objek immutable yang didefinisikan oleh nilai-nilainya, bukan identity.
- Aggregate: Cluster entity + value object yang diperlakukan sebagai unit; root adalah entry point.
- Domain Event: Fact bahwa sesuatu telah terjadi di domain; immutable dan past-tense.
- Repository: Interface yang menyembunyikan persistence details; collection-like abstraction.
- Domain Service: Logic yang tidak cocok di entity manapun; stateless operations.
Berikut adalah Cetak Biru Tactical Domain-Driven Design (DDD) yang memvisualisasikan batas konsistensi transaksional sebuah Aggregate, integrasi Entity dan Value Object, serta interaksinya dengan Domain Repository dan Domain Event:
7. Data & Storage Patterns
7.1 Data Access Patterns
| Pola | Era | Penggunaan | Keunggulan | Tantangan |
|---|---|---|---|---|
| Repository Pattern | 🔵 Classic | Data access abstraction layer | Testable, swappable storage | Leaky abstraction risk |
| Active Record | 🔵 Classic | Rails ORM, Laravel Eloquent | Simple, DRY | Mixes domain and data logic |
| Data Mapper | 🔵 Classic | Doctrine ORM, Hibernate | Domain purity | More complex setup |
| DAO (Data Access Object) | 🔵 Classic | Java EE, traditional enterprise | Separation of concerns | Can be verbose |
| Unit of Work | 🔵 Classic | ORMs, transaction management | Atomic operations | Complex tracking |
| Identity Map | 🔵 Classic | ORM internals | Avoids duplicate queries | Memory usage |
| Lazy Loading | 🔵 Classic | ORMs, performance optimization | Performance | N+1 query problem |
| Eager Loading | 🔵 Classic | Avoiding N+1 query | Avoids N+1 | May load unneeded data |
7.2 Caching Patterns
| Pola | Era | Penggunaan | Keunggulan | Tantangan |
|---|---|---|---|---|
| Cache-Aside (Lazy Loading) | 🔵 Classic | Redis, Memcached — most common | Only cache what's used | Cache miss latency |
| Write-Through | 🔵 Classic | Consistent cache | Cache always consistent | Write latency increases |
| Write-Behind (Write-Back) | 🔵 Classic | High-write scenarios | Write performance | Data loss risk |
| Read-Through | 🔵 Classic | Cache libraries | Transparent caching | Requires cache provider support |
| Refresh-Ahead | 🟢 Modern | Predictable access patterns | No miss latency | Predictability required |
| Distributed Cache | 🟢 Modern | Redis Cluster, Hazelcast | Scales horizontally | Consistency challenges |
| CDN Pattern | 🟢 Modern | Static assets, global apps | Global low latency | Cache invalidation |
| Materialized View | 🔵 Classic | Read-heavy reporting | Read performance | Stale data |
Deskripsi:
- Cache-Aside: App cek cache dulu; jika miss, load dari DB lalu simpan ke cache.
- Write-Through: Setiap write ke DB juga write ke cache sekaligus.
- Write-Behind: Write ke cache dulu; sync ke DB async.
- Read-Through: Cache transparan: miss otomatis load dari DB via cache provider.
- Refresh-Ahead: Cache di-refresh sebelum expired berdasarkan prediksi akses.
- Materialized View: Precompute dan simpan hasil query kompleks sebagai table tersendiri.
7.3 Database Patterns
| Pola | Era | Penggunaan | Keunggulan | Tantangan |
|---|---|---|---|---|
| Sharding | 🟢 Modern | Horizontal DB scaling | Horizontal scaling | Cross-shard queries hard |
| Read Replica | 🔵 Classic | Read-heavy workloads | Read scaling | Replication lag |
| Database per Service | 🟢 Modern | Microservices | Service independence | Distributed queries hard |
| Shared Database | 🔵 Classic | Simple systems, monoliths | Simple queries | Coupling via schema |
| SAGA Pattern | 🟢 Modern | Distributed transactions | No 2PC needed | Complex compensation logic |
| Polyglot Persistence | 🟢 Modern | Choose right DB per need | Optimal storage per use case | Operational complexity |
| Multi-Model Database | 🟢 Modern | ArangoDB, CosmosDB | Reduced complexity | Jack of all trades |
| Temporal Table | 🟢 Modern | Audit log, time-travel queries | Built-in history | Storage growth |
Deskripsi:
- Sharding: Partisi database secara horizontal berdasarkan sharding key untuk skalabilitas penyimpanan.
- CQRS: Memisahkan model penulisan data (Command) dan pembacaan data (Query) untuk mengoptimalkan kinerja.
- Cache-Aside: Aplikasi memeriksa cache dahulu; jika miss, mengambil dari DB lalu mengisi cache secara asinkronus.
- SAGA: Koordinasi transaksi terdistribusi pada mikroservis melalui serangkaian transaksi lokal dengan logika kompensasi.
Berikut adalah Cetak Biru CQRS & Caching Patterns Architecture yang memvisualisasikan pemisahan jalur tulis-baca (CQRS) serta siklus hidup pemuatan data asinkronus (Cache-Aside (Lazy Loading) Pattern Flow):
8. AI & ML System Patterns
8.1 ML System Architecture
| Pola | Era | Penggunaan | Keunggulan | Tantangan |
|---|---|---|---|---|
| Feature Store | 🟢 Modern | Uber Michelangelo, Feast, Tecton | Feature reuse, consistency | Extra infrastructure |
| Model Registry | 🟢 Modern | MLflow, SageMaker Registry | Model governance | Process overhead |
| Two-Tower Architecture | 🟢 Modern | Recommendation systems (YouTube, TikTok) | Scalable retrieval | Complex training |
| Lambda ML Architecture | 🟢 Modern | Real-time + batch ML serving | Combines batch accuracy + real-time | Dual system maintenance |
| Online Learning | 🟢 Modern | Fraud detection, recommendation | Always fresh | Unstable if data distribution shifts |
| Federated Learning | 🔴 Research | Mobile privacy, healthcare | Data privacy | Communication overhead, heterogeneous |
| Model Distillation Architecture | 🟢 Modern | Edge deployment | Smaller, faster model | Accuracy loss |
| Mixture of Experts Serving | 🔴 Research | LLM inference optimization | Scales to large models | Complex routing |
Deskripsi:
- Feature Store: Central repository untuk fitur ML yang bisa dishare antar model; training-serving consistency.
- Model Registry: Version control dan catalog untuk ML models; metadata, lineage, deployment tracking.
- Two-Tower: Dua tower neural network: satu encode user, satu encode item; dot product untuk similarity.
- Federated Learning: Model ditraining di device lokal; hanya gradients yang dikirim ke server, bukan data.
- Model Distillation: Train model kecil (student) untuk meniru model besar (teacher).
8.2 LLM & GenAI Patterns
| Pola | Era | Penggunaan | Keunggulan | Tantangan |
|---|---|---|---|---|
| RAG (Retrieval-Augmented Generation) | 🟢 Modern | Enterprise knowledge base, chatbot | Grounded responses | Retrieval quality dependent |
| Agentic Architecture | 🟢 Modern | AutoGPT, LangChain agents | Complex task completion | Unpredictable, hard to debug |
| Multi-Agent System | 🟢 Modern | CrewAI, AutoGen | Parallel specialized agents | Coordination complexity |
| ReAct Pattern | 🟢 Modern | LLM reasoning with tool use | Explicit reasoning chain | Verbose, slow |
| Chain-of-Thought (CoT) | 🟢 Modern | Complex reasoning tasks | Better reasoning accuracy | Higher token usage |
| Tree of Thoughts (ToT) | 🔴 Research | Complex planning, search | Better than CoT for complex problems | Very high token usage |
| Prompt Chaining | 🟢 Modern | Multi-step LLM pipelines | Modular LLM logic | Error propagation |
| LLM Cache Pattern | 🟢 Modern | Reduce LLM cost | Cost reduction | Semantic similarity matching is hard |
| Guardrails Pattern | 🟢 Modern | LLM safety & control | Safety & reliability | Added latency |
| Human-in-the-Loop | 🟢 Modern | High-stakes AI decisions | Safety net | Bottleneck |
| Vector Store Pattern | 🟢 Modern | Semantic search, RAG | Semantic retrieval | Dimensionality curse |
| Embedding Cache | 🟢 Modern | RAG optimization | Cost and latency savings | Cache invalidation on model change |
Deskripsi:
- RAG: Augment LLM dengan retrieval dari knowledge base; reduce hallucination.
- Agentic Architecture: LLM bertindak sebagai agent yang bisa planning, tool use, dan multi-step reasoning.
- Multi-Agent System: Beberapa LLM agent bekerja sama dengan role berbeda.
- ReAct: Interleave reasoning dan acting; think → act → observe → think...
- CoT: Prompt LLM untuk reason step by step sebelum menjawab.
- Tree of Thoughts: Branching reasoning: explore multiple thought paths, backtrack, evaluate.
- Guardrails: Layer validasi untuk check input/output LLM: content policy, format, hallucination.
- Vector Store: Simpan dan query dense vector embeddings untuk semantic similarity search.
Berikut adalah Cetak Biru System Patterns: Retrieval-Augmented Generation (RAG) Flow yang memetakan integrasi mesin pencarian kesamaan semantik (Vector DB) ke dalam generasi augmentasi teks model bahasa besar (LLM):
9. Frontend Architecture Patterns
9.1 Rendering Patterns
| Pola | Era | Penggunaan | Keunggulan | Tantangan |
|---|---|---|---|---|
| CSR (Client-Side Rendering) | 🔵 Classic | SPAs: React, Vue, Angular apps | Rich interactivity | Poor initial load, SEO challenges |
| SSR (Server-Side Rendering) | 🔵 Classic | Next.js, Nuxt, SvelteKit | Fast initial paint, SEO | Server load per request |
| SSG (Static Site Generation) | 🟢 Modern | Blogs, docs, marketing sites | Super fast, secure | Dynamic content needs redeployment |
| ISR (Incremental Static Regeneration) | 🟢 Modern | Next.js hybrid sites | Fresh content without full rebuild | Stale window exists |
| Partial Hydration | 🟢 Modern | Astro, Islands architecture | Minimum JS sent | Complex component isolation |
| Islands Architecture | 🟢 Modern | Astro, Eleventy + Alpine | Performance by default | Inter-island communication hard |
| Streaming SSR | 🟢 Modern | React 18+, Next.js App Router | Faster TTFB | Complex mental model |
| Edge Rendering | 🔴 Research | Vercel Edge, Cloudflare Workers | Global low latency SSR | Runtime limitations |
Deskripsi:
- CSR: JavaScript me-render semua UI di browser; server hanya kirim HTML shell.
- SSR: Server render HTML penuh untuk setiap request; client hydrates.
- SSG: HTML di-generate saat build time; served via CDN.
- ISR: Static + periodic regeneration; stale-while-revalidate untuk SSG.
- Islands Architecture: Static HTML dengan 'islands' interaktif terisolasi.
- Streaming SSR: Server stream HTML ke client secara bertahap menggunakan Suspense.
- Edge Rendering: SSR dilakukan di edge nodes dekat user; ultra-low latency rendering.
9.2 State & Data Patterns
| Pola | Era | Penggunaan | Keunggulan | Tantangan |
|---|---|---|---|---|
| Flux / Redux | 🟢 Modern | Complex React state | Predictable | Boilerplate |
| Atomic State (Jotai, Recoil) | 🟢 Modern | React fine-grained state | Fine-grained subscriptions | Atom coordination |
| Reactive State (MobX, Signals) | 🟢 Modern | Fine-grained reactive updates | Less boilerplate | Magic behavior |
| Server State (React Query, SWR) | 🟢 Modern | Data fetching, cache sync | Less code for async state | Learning curve |
| URL as State | 🔵 Classic | Shareable URLs, deep linking | Shareable | Limited storage |
| Optimistic UI | 🟢 Modern | Social apps, real-time feeling | Snappy UX | Rollback complexity |
9.3 Component Architecture Patterns
| Pola | Era | Penggunaan | Keunggulan | Tantangan |
|---|---|---|---|---|
| Compound Components | 🟢 Modern | Reusable component libraries | Flexible composition | Implicit coupling |
| Render Props | 🔵 Classic | React code reuse (pre-hooks) | Flexible reuse | Callback hell |
| Higher-Order Components (HOC) | 🔵 Classic | React cross-cutting concerns | Code reuse | Wrapper hell, prop collision |
| Headless Components | 🟢 Modern | Radix UI, Headless UI, React Hook Form | Full style control | More setup |
| Container/Presentational | 🔵 Classic | Separating logic from UI | Separation of concerns | Extra files |
| Module Federation | 🟢 Modern | Webpack 5, micro-frontend | True micro-frontend | Version coordination |
Deskripsi:
- SSR (Server-Side Rendering): Halaman HTML di-render di server untuk setiap request, lalu dikirim ke client dan di-hidrasi (hydration).
- SSG (Static Site Generation): Semua halaman statis di-render saat build time; disajikan instan via CDN.
- SPA (Single Page Application): Unduh satu berkas HTML minimal, lalu browser melakukan manipulasi DOM dinamis dan pemuatan data asinkronus via JS.
Berikut adalah Cetak Biru Frontend Rendering Patterns: SSR vs SSG vs SPA Lifecycle & Hydration Flow yang menggambarkan siklus hidup pembuatan halaman web dari server hingga penanganan interaktif di browser klien:
10. Mobile Architecture Patterns
| Pola | Era | Penggunaan | Keunggulan | Tantangan |
|---|---|---|---|---|
| VIPER (iOS) | 🟢 Modern | iOS clean architecture | Testable | Very verbose |
| Redux (Mobile) | 🟢 Modern | React Native, KMP | Predictable state | Boilerplate |
| ViewModel + LiveData | 🟢 Modern | Android Architecture Components | Lifecycle aware | Android-specific |
| Unidirectional Data Flow (UDF) | 🟢 Modern | SwiftUI, Jetpack Compose | Predictable | Verbose for simple cases |
| Clean Architecture (Mobile) | 🟢 Modern | Android & iOS enterprise apps | Framework independent | Verbosity |
| Offline-First | 🟢 Modern | Apps in poor connectivity | Works anywhere | Conflict resolution complex |
| Local-First Architecture | 🔴 Research | CRDTs, sync apps | Privacy, offline | Sync complexity |
| Mini-app Architecture | 🟢 Modern | WeChat Mini Programs, Super Apps | Ecosystem leverage | Platform dependency |
Deskripsi:
- VIPER: View-Interactor-Presenter-Entity-Router; fine-grained separation.
- Offline-First: App berfungsi offline; sync ke server saat ada koneksi.
- Local-First: Data lokal adalah primary; server adalah sync target.
- Mini-app: App di dalam app; sandboxed environment dengan shared OS.
Berikut adalah Cetak Biru Perbandingan Pola Presentasi Mobile (MVC vs MVP vs MVVM) yang memvisualisasikan bagaimana alur kontrol dan data mengalir antara komponen visual antarmuka pengguna, logika aplikasi, dan model data:
11. Real-Time & Streaming Patterns
11.1 Real-Time Patterns
| Pola | Era | Penggunaan | Keunggulan | Tantangan |
|---|---|---|---|---|
| WebSocket Server Pattern | 🟢 Modern | Chat, gaming, trading | True real-time | Stateful, scaling hard |
| Long Polling | 🔵 Classic | Legacy real-time, fallback | Works everywhere | Resource inefficient |
| Server-Sent Events | 🟢 Modern | Live feeds, notifications | Simple, HTTP-native | One-directional |
| CRDT Architecture | 🔴 Research | Collaborative apps (Figma, Notion) | No conflict | CRDT design is complex |
| Operational Transform (OT) | 🔵 Classic | Google Docs, collaborative editing | Proven for text editing | Complex to implement correctly |
| Presence System | 🟢 Modern | Online indicators, cursors | Collaborative awareness | Scalable presence is hard |
Deskripsi:
- WebSocket Server: Maintain persistent connections; broadcast updates ke semua atau specific rooms.
- Long Polling: Client kirim request; server hold sampai ada update atau timeout.
- CRDT: Conflict-free Replicated Data Types; merge concurrent edits tanpa conflict.
- Operational Transform: Transform operasi concurrent untuk mempertahankan konsistensi.
- Presence System: Track siapa yang online dan apa yang mereka lakukan secara real-time.
11.2 Stream Processing Patterns
| Pola | Era | Penggunaan | Keunggulan | Tantangan |
|---|---|---|---|---|
| Dataflow Architecture | 🟢 Modern | Apache Beam, Google Dataflow | Portable | Abstraction overhead |
| Micro-batch Processing | 🟢 Modern | Spark Structured Streaming | Exactly-once semantics | Mini-latency |
| Continuous Processing | 🟢 Modern | Flink, Kafka Streams | Lowest latency | State management complex |
| Windowing Patterns | 🟢 Modern | Tumbling, sliding, session windows | Temporal aggregation | Late data handling |
| Watermark Pattern | 🟢 Modern | Event-time processing | Handles late data | Tradeoff latency vs correctness |
Deskripsi:
- Dataflow: Processing pipeline sebagai directed graph; portabel across batch dan streaming.
- Micro-batch: Proses data dalam interval kecil (detik); antara batch dan true streaming.
- Continuous Processing: Proses setiap event saat tiba; true streaming.
- Windowing: Grouping events dalam window waktu untuk aggregation.
- Watermark: Heuristic untuk menentukan kapan semua data untuk waktu tertentu sudah tiba.
Berikut adalah Cetak Biru Real-Time & Streaming Patterns (WebSocket Architecture) yang memetakan pertukaran pesan dua arah berlatensi rendah secara persisten antara klien peramban dan server orkestrasi:
12. Testing & Quality Patterns
| Pola | Era | Penggunaan | Keunggulan | Tantangan |
|---|---|---|---|---|
| Test Pyramid | 🔵 Classic | All software projects | Fast feedback | E2E coverage gaps |
| Test Trophy (Kent C. Dodds) | 🟢 Modern | Frontend testing | More realistic tests | Slower than unit tests |
| BDD (Behavior-Driven Development) | 🔵 Classic | Cucumber, SpecFlow | Shared understanding | Maintenance overhead |
| TDD (Test-Driven Development) | 🔵 Classic | Clean code, refactoring | Design by tests | Initial slowdown |
| Property-Based Testing | 🟢 Modern | QuickCheck, Hypothesis | Finds edge cases | Harder to write |
| Contract Testing | 🟢 Modern | Pact, microservice API contracts | Catches breaking changes early | Contract maintenance |
| Snapshot Testing | 🟢 Modern | React component testing (Jest) | Easy regression catch | False negatives from intentional changes |
| Mutation Testing | 🟢 Modern | Test quality assessment | Measures test quality | Slow to run |
| Chaos Engineering | 🟢 Modern | Netflix, resilience testing | Finds real weaknesses | Risky if done wrong |
| Load Testing Patterns | 🔵 Classic | Gatling, k6, JMeter | Capacity planning | Realistic simulation is hard |
Deskripsi:
- Test Pyramid: Unit tests (banyak) → Integration (sedikit) → E2E (sangat sedikit).
- Test Trophy: Integration tests lebih banyak dari unit; fokus pada 'confidence'.
- BDD: Tests ditulis dalam bahasa natural (Given-When-Then); kolaborasi dev-QA-business.
- TDD: Red-Green-Refactor: tulis test dulu, baru implementasi.
- Property-Based Testing: Generate ribuan input acak untuk test property yang harus selalu true.
- Contract Testing: Test bahwa API contract antara producer dan consumer terpenuhi.
- Chaos Engineering: Sengaja inject failure ke produksi untuk test ketahanan sistem.
Berikut adalah Cetak Biru Testing & Quality Patterns (Whiteboard System Architecture Testing) yang memetakan jalur validasi logika, kontrol, dan pengujian integrasi modular pada arsitektur sistem perangkat lunak yang kompleks secara terstruktur:
Ringkasan Statistik
| Kategori | Jumlah Pola |
|---|---|
| System Architecture Styles | 34 |
| Application Architecture Patterns | 24 |
| Design Patterns (GoF & Beyond) | 34 |
| Enterprise Integration Patterns | 32 |
| Cloud & DevOps Patterns | 23 |
| Domain-Driven Design (DDD) | 17 |
| Data & Storage Patterns | 24 |
| AI & ML System Patterns | 20 |
| Frontend Architecture Patterns | 20 |
| Mobile Architecture Patterns | 8 |
| Real-Time & Streaming Patterns | 11 |
| Testing & Quality Patterns | 10 |
| Total | ~257 pola unik |
Referensi & Sumber Lanjutan
- Design Patterns — Design Patterns: Elements of Reusable Object-Oriented Software (GoF, 1994)
- Enterprise Integration Patterns — Gregor Hohpe & Bobby Woolf — enterpriseintegrationpatterns.com
- Domain-Driven Design — Eric Evans (2003), Vaughn Vernon Implementing Domain-Driven Design (2013)
- Clean Architecture — Robert C. Martin ("Uncle Bob") (2017)
- Hexagonal Architecture — Alistair Cockburn — alistair.cockburn.us
- Patterns of Enterprise Application Architecture — Martin Fowler (2002)
- Building Microservices — Sam Newman (2nd ed, 2021)
- Designing Data-Intensive Applications — Martin Kleppmann (2017)
- Cloud Design Patterns — Microsoft Azure — learn.microsoft.com
- AWS Architecture Center — aws.amazon.com/architecture
- LLM Patterns — Eugene Yan — eugeneyan.com