Systems Toolbox

The basic mental models behind databases, caches, queues, logs, search engines, coordination stores, and workflow systems.

First principle Tools are bundles of trade-offs. Start with the workload and invariant, then choose the simplest tool whose behavior matches them.

Map Tools to Jobs

Transactions
PostgreSQLMongoDB
Fast shared state
Redis
Replayable events
Kafka
Background work
SQSRabbitMQ
Global scale data
CassandraDynamoDB
Search
Elasticsearch / OpenSearch
Files and blobs
S3-compatible object storage
Coordination
etcd
Long workflows
Temporal
Metrics
Prometheus
Flexible documents
MongoDB
Relational source of truth
PostgreSQL

Explore a Payment System

One system does not need every tool. This design uses each component for a specific job. Select a component to inspect its role and connections.

Synchronous request Kafka event stream Queue delivery Workflow command Storage write Replication / CDC Metrics scrape
How to read: Boxes are components. Labeled arrows are data movement. Select either one: related paths stay bright while unrelated parts dim.
Clickable payment platform architecture A client reaches payment services through an API gateway. Services use PostgreSQL, Redis, Kafka, SQS, and Temporal. Transactional events reach Kafka through an outbox relay, while services may also publish directly. Consumer groups process events, failed jobs reach a dead-letter queue, and PostgreSQL replicates reads. CLIENT EDGE APPLICATION SERVICES TRANSACTIONAL AND DELIVERY LAYER ASYNC PROCESSING AND DERIVED DATA HTTPS SQL + TXN GET / SET PUBLISH EVENT DIRECT PRODUCE WAL SEND JOB HTTPS API ACTIVITY CALL POLL + OFFSET RECEIVE + ACK REDRIVE TASK QUEUE INDEX DOC PUT OBJECT GET /metrics Client WEB / MOBILE API Gateway ROUTING Py Payment API PYTHON SERVICE PostgreSQL PRIMARY / WRITES Read Replica READS / FAILOVER Outbox Relay POLL / CDC Temporal DURABLE WORKFLOW Redis CACHE + LIMITS Kafka PARTITIONED LOG SQS Amazon SQS WORK QUEUE Payment Provider EXTERNAL NETWORK Consumer Groups RISK / RECON / SEARCH Dead-letter Queue FAILED JOBS Go Worker Services IDEMPOTENT CONSUMERS OpenSearch SEARCH PROJECTION S3 Amazon S3 FILES + EXPORTS Prometheus METRICS

Tip: click blank diagram space or press Escape to clear the selection.

Choose by Workload

Select the primary job. The result is a starting point, not an architecture generator.

Choose a workload

The recommendation will explain the useful starting tool and the main caveat.

Databases and Data Stores

PostgreSQL

Relational OLTP
Official site ↗

A general-purpose transactional database built around tables, SQL, constraints, indexes, MVCC, and WAL.

How it works
Rows live in heap pages. Indexes provide alternate access paths. Transactions use MVCC and locks. WAL enables crash recovery and replication.
Key concepts
transactionsconstraintsMVCCindexesWALreplicas
Use for
Systems of record, money, orders, accounts, joins, and data with strong invariants.
Trade-off
Scaling writes across many nodes is harder than scaling a partition-native database.
Back to tool picker

Redis

In-memory data structures
Official site ↗

A low-latency server exposing strings, hashes, sets, sorted sets, streams, counters, and expiration.

How it works
Commands modify in-memory structures through a mostly single-threaded execution model. Optional RDB snapshots or AOF logs persist data.
Key concepts
TTLevictionRDBAOFreplicationcluster slots
Use for
Caches, counters, rate limits, sessions, leaderboards, short-lived coordination, and fast derived state.
Trade-off
Memory is expensive, durability depends on configuration, and slow commands can stall unrelated clients.
Back to tool picker

Cassandra

Wide-column distributed DB
Official site ↗

A partition-first database for high write volume, large data sets, multi-node availability, and predictable access patterns.

How it works
A partition key maps data to token ranges and replicas. Writes follow an LSM path: commit log, memtable, then immutable SSTables and compaction.
Key concepts
partition keyclustering columnsreplication factorconsistency levelSSTablecompaction
Use for
Massive write-heavy time-series or event data with known query patterns and high availability requirements.
Trade-off
No joins, limited ad hoc queries, careful partition sizing, and data modeling must begin from access patterns.
Back to tool picker

MongoDB

Document database
Official site ↗

Stores JSON-like documents and favors embedding related data that is commonly read together.

How it works
Replica sets elect a primary and asynchronously apply its oplog to secondaries. Sharding distributes documents using a shard key and query routers.
Key concepts
documentscollectionsreplica setoplogshard keyread/write concern
Use for
Flexible records, content, catalogs, user profiles, and domains where aggregate-shaped documents fit naturally.
Trade-off
Embedding can duplicate data; cross-document transactions and poor shard keys add distributed complexity.
Back to tool picker

DynamoDB

Managed key-value/document DB
Official site ↗

An AWS-managed, partitioned database designed around predictable key-based access at large scale.

How it works
A partition key determines data placement. Sort keys group ordered items. Secondary indexes create additional access paths. AWS manages replication and partitions.
Key concepts
partition keysort keyGSILSIcapacitystreams
Use for
Serverless or AWS-native systems with known access patterns, high scale, and minimal database operations work.
Trade-off
Modeling is access-pattern-first, hot keys remain possible, and ad hoc relational queries are a poor fit.
Back to tool picker

Elasticsearch / OpenSearch

Search and analytics
Elastic ↗OpenSearch ↗

Distributed search engines built on inverted indexes, optimized for relevance, filtering, and aggregations.

How it works
Documents are analyzed into terms and written to Lucene segments. An index is split into primary shards and replica shards across nodes.
Key concepts
mappinganalyzerinverted indexsegmentshardrefresh
Use for
Full-text search, logs, observability search, faceting, and relevance-ranked retrieval.
Trade-off
Near-real-time visibility, costly updates, shard overhead, and usually a poor primary source of truth.
Back to tool picker

Messaging: Queue or Log?

Queue: work is claimed

Producer
→
Queue
→
One worker

A queue distributes tasks. A message is acknowledged or deleted after processing. Retries return failed work for another attempt.

Log: history is retained

Producer
→
Partition log
→
Many readers

A log retains ordered events. Consumers track offsets and may replay history independently.

Kafka

Distributed event log
Official site ↗

A replayable, partitioned log for durable event streams and independent consumer groups.

How it works
Producers append records to topic partitions. Each partition has an ordered offset sequence, a leader, and replicas. Consumers advance offsets.
Key concepts
topicpartitionkeyoffsetconsumer groupISRretention
Use for
Event backbones, CDC, audit streams, stream processing, replay, and many independent consumers.
Trade-off
Ordering exists only inside one partition; partition count, key choice, lag, and rebalances become operational concerns.
Back to tool picker

Amazon SQS

Managed work queue
Official site ↗

A fully managed AWS queue for decoupling producers from background workers.

How it works
A consumer receives a message, which becomes hidden for a visibility timeout. It deletes the message after success; otherwise the message becomes visible again.
Key concepts
visibility timeoutat-least-oncelong pollingDLQredriveFIFO groups
Use for
AWS background jobs where simple operations, automatic scaling, and low maintenance matter.
Trade-off
Standard queues can duplicate and reorder messages. Routing and replay are much more limited than RabbitMQ or Kafka.
Back to tool picker

RabbitMQ

Message broker
Official site ↗

A broker with flexible routing between publishers, exchanges, bindings, queues, and consumers.

How it works
Publishers send to exchanges. Exchange type and bindings route each message to queues. Consumers acknowledge deliveries. Quorum queues replicate through Raft.
Key concepts
exchangebindingqueueack/nackprefetchpublisher confirmquorum queue
Use for
Work queues, request routing, priorities, per-message retries, and sophisticated message topologies.
Trade-off
More topology and broker operations than SQS; less natural replay and event history than Kafka.
Back to tool picker

Platform Building Blocks

S3-compatible storage

Object storage
Official site ↗

Stores byte objects addressed by bucket and key, separate from a filesystem or relational schema.

How it works
Clients PUT and GET complete objects. Metadata, versioning, lifecycle rules, multipart upload, replication, and access policy surround the object.
Key concepts
bucketobject keyversionmultipartpresigned URLlifecycle
Use for
Images, videos, documents, backups, archives, exports, and data lakes.
Trade-off
Not a POSIX filesystem or query engine. Object updates replace the object rather than editing arbitrary blocks in place.
Back to tool picker

etcd

Consensus key-value store
Official site ↗

A small, strongly consistent store for configuration, service discovery, leader election, and cluster metadata.

How it works
A Raft group orders writes. Keys have monotonically increasing revisions. Clients can watch changes and attach keys to expiring leases.
Key concepts
Raftrevisionwatchleasetransactioncompaction
Use for
Small, critical coordination data. Kubernetes uses etcd for cluster state.
Trade-off
Not for large values, high write volume, analytics, or ordinary application records.
Back to tool picker

Temporal

Durable workflow engine
Official site ↗

Runs long-lived business workflows that resume after worker crashes, process restarts, and infrastructure failures.

How it works
The service persists workflow event history. Workflow code is replayed deterministically to reconstruct state. Activities perform external side effects and are retried.
Key concepts
workflowactivityhistoryreplaytimersignalretry
Use for
Payment flows, fulfillment, onboarding, scheduled work, human approval, and multi-day processes.
Trade-off
Workflow determinism, versioning running executions, another operational dependency, and activity idempotency.
Back to tool picker

Prometheus

Metrics and alerting
Official site ↗

A pull-based monitoring system and time-series database for numeric measurements with labels.

How it works
Prometheus scrapes metric endpoints on an interval, stores labeled time series, evaluates PromQL queries, and sends alerts through Alertmanager.
Key concepts
countergaugehistogramlabelscrapePromQLcardinality
Use for
Service health, latency, throughput, errors, saturation, queue depth, and alerting.
Trade-off
High-cardinality labels are expensive. Metrics summarize behavior; they do not replace logs or traces.
Back to tool picker

Quick Comparison

ToolPrimary modelOrdering / consistencyScaling unitBest remembered as
PostgreSQLRelational rowsACID transactions; configurable isolationDatabase, table, replicaTransactional source of truth
RedisIn-memory structuresAtomic command execution; replication caveatsKey / hash slotFast shared derived state
KafkaPartitioned append logTotal order per partitionPartitionReplayable event history
SQSManaged queueAt-least-once; FIFO within message group when selectedQueue / message groupSimple managed background work
RabbitMQBrokered queuesAcks, confirms, queue-specific orderingQueueFlexible routing and work delivery
CassandraWide-column partitionsTunable consistencyPartition / token rangeAlways-on, write-heavy distributed data
MongoDBDocumentsRead and write concerns; transactions availableCollection / shard keyAggregate-shaped flexible records
DynamoDBKey-value and documentsEventually consistent by default; strong table reads optionalPartition keyManaged access-pattern-first database
ElasticsearchInverted search indexNear-real-time searchShardSearchable projection of source data
S3Objects by keyStrong read-after-write for object operationsObject / prefixDurable blob storage
etcdVersioned key-valueLinearizable writes through RaftRaft clusterSmall critical coordination state
TemporalWorkflow event historyDurable deterministic replayWorkflow executionReliable long-running control flow
PrometheusLabeled time seriesPeriodic samplesSeries / scrape targetMetrics and alerting

Decision Rules

Start with PostgreSQL until a measured workload or required behavior proves it is the wrong tool.
Use Redis as a cache or derived-state accelerator, not automatically as a second source of truth.
Choose Kafka when replay and independent readers matter; choose a queue when work should be claimed and completed.
Assume messages can be duplicated. Put idempotency at the side-effect boundary.
In partitioned databases, the partition key is an architecture decision, not merely a schema field.
Use Elasticsearch as a searchable projection. Keep authoritative records elsewhere.
Use etcd only for small coordination state. Consensus is valuable and expensive.
Adopt Temporal when durable timers, retries, signals, or multi-day state justify its operational and coding model.

Official Sources