Key Technologies Overview
Choose a technology from required behavior and operating constraints.
Choose a technology from required behavior and operating constraints. The technology chapters explain mechanisms and trade-offs, but no product name replaces API semantics, workload estimates, or failure handling. This index groups ten technologies by the job they can perform in a design.
The mechanism at a glance
Figure — Workload → Guarantee (requirements); Guarantee → Technology mechanism (compare product behavior); Technology mechanism → Operational limit (capacity and failure); Operational limit → Recovery test (replay or failover); Recovery test → Choice (justify smallest fit)
The numbered components identify responsibilities. Follow the labeled arrows rather than treating the numbers as a global execution order. The scenario later in this lesson shows one concrete sequence.
Step-by-step reasoning
1. 1 · Frame
Redis covers in-memory data structures, caches, and bounded coordination. Elasticsearch covers text retrieval and indexing. Kafka covers partitioned event logs and replay. Temporal covers durable workflow execution. API Gateway covers edge routing and policy. Compare these against the workload rather than assuming a default product is always correct.
2. 2 · Model
Cassandra and DynamoDB are distributed stores whose data model should follow access patterns and partition behavior. PostgreSQL provides relational constraints and transactions. Flink processes stateful event streams with event time, windows, and checkpointing. ZooKeeper coordinates small critical shared state and membership-like decisions with sessions and ephemeral nodes.
3. 3 · Scale
For each candidate, ask: what is durable, what is the ordering/consistency scope, how is it partitioned, how does it recover, what is the operational burden, and what happens at saturation? Read the corresponding chapter and return to the system case that motivated the choice.
4. 4 · Recover
Prefer a familiar tool when its guarantees fit. Do not use a cache as the only inventory authority, an event log as an arbitrary query database, or a coordination service for high-volume application records. Product capabilities and managed service limits change; verify version-specific documentation before production decisions.
Contracts and state
The following sketch makes the decision boundary concrete. Field names and capacity assumptions are illustrative; adapt them to the stated product contract.
Workload -> guarantee -> access pattern -> partition -> recovery -> technology fit
Redis / Elasticsearch / Kafka / Temporal / API Gateway
Cassandra / DynamoDB / PostgreSQL / Flink / ZooKeeperWorked example
A payment flow needs durable relational constraints and a recoverable multi-step provider interaction. PostgreSQL can own payment state; an outbox publishes the transition; Temporal can coordinate durable workflow steps. The combination is justified by distinct responsibilities, not by using more products for its own sake.
Failure walkthrough
A design stores user state in a queue because the queue already exists, then discovers it needs indexed queries, updates, and transactional uniqueness. Revisit the access pattern and ownership: event transport and system-of-record storage solve different problems.
Figure — Need is named → Guarantee is stated → Mechanism is compared → Saturation is considered → Recovery is tested
Decisions and trade-offs
| Need | Candidate chapters | Decision to explain |
|---|---|---|
| Fast ephemeral structures | Redis | Eviction and source of truth |
| Text retrieval | Elasticsearch | Refresh lag and authorization |
| Ordered replayable events | Kafka | Partition key and consumer lag |
| Durable business workflow | Temporal | Retry and side-effect identity |
| Relational invariants / scale stores | PostgreSQL, Cassandra, DynamoDB | Transactions and key model |
| Stateful streams / coordination | Flink, ZooKeeper | Checkpoint or session failure |
Check your understanding
Select technologies for a notification flow that needs durable intent, retryable delivery, and searchable status. Explain why each component is separate.
Show answer and explanation
Answer: Use a durable system of record for notification intent/status; a queue or log for dispatch may distribute work; workers call providers idempotently and write outcomes back. A workflow engine can coordinate long-running provider attempts when its operational guarantees are needed. Search indexing is a derived projection with explicit lag and authorization.
Open a chapter
Select technologies for a notification flow that needs durable intent, retryable delivery, and searchable status. Explain why each component is separate.
Your design draft
Clarify assumptions, explain your approach, and test the difficult cases. Save your draft, then compare it with the study notes.
Self-review checklist
Self-guided practice. Automated AI feedback and code execution are not connected.