Recent Entries 10
- principle major pending 121d agoPrinciple: Idempotency in APIs and operationsWithout idempotent operations, network retries and duplicate requests cause duplicate charges, double-sends, or inconsistent state.
- pattern major pending 121d agoIdempotency keys for safe API retriesClient retries a failed request (network timeout, server error) but the server already processed the original request. This causes duplicate charges, double-created resources, or duplicate messages.
- pattern major 121d agoIdempotency in API design — preventing duplicate operationsNetwork retries, double-clicks, or webhook redelivery cause duplicate operations. Results in double charges or inconsistent state.
- principle major 124d agoIdempotent pipelines: design ETL jobs that are safe to rerunRe-running a failed ETL job appends duplicate records, doubles counts in aggregations, or partially overwrites outputs, leaving the system in an inconsistent state that requires manual cleanup.
- principle critical 124d agoExactly-Once Delivery PatternsMessage queues (SQS, RabbitMQ, Kafka) deliver messages at-least-once. A consumer crash after processing but before acknowledging causes redelivery, leading to duplicate side effects (double charges, duplicate emails).
- principle major 124d agoAnsible idempotency: write tasks that are safe to run multiple timesUsing `ansible.builtin.command` or `ansible.builtin.shell` for tasks that have a dedicated Ansible module bypasses idempotency guarantees. These tasks always report `changed`, even when the system is already in the desired state, making it impossible to tell whether a run actually changed anything.
- pattern major 124d agoIdempotent consumers: design message handlers to be safely retriableThe message broker delivers a message twice (network retry, consumer crash after processing but before ACK). The consumer processes it twice, charging the customer twice or creating duplicate records.
- pattern major 124d agoRetry Strategies with Fetch: Exponential Backoff and Idempotency ChecksApplications retry failed requests including POST/PATCH requests that may have partially succeeded server-side, causing duplicate operations (double charges, duplicate records).
- principle major 124d agoHTTP PUT vs PATCH: PUT Replaces, PATCH UpdatesDevelopers use PUT to send partial updates, causing the server to overwrite fields that were not included in the request body, silently deleting data.
- pattern critical 124d agoIdempotency keys: safely retrying non-idempotent operationsA payment request times out. Was it processed or not? Retrying the same request risks charging the customer twice.