tl;dr:Several PostgreSQL patterns that might not be immediately obvious to many developers including: (1) Always define explicit ON DELETE semantics. (2) If in doubt, use ON DELETE SET NULL. (3) Mutually exclusive columns. (4) Prohibit hidden nulls in jsonb columns. (5) Declare your updated\_at columns NOT NULL to make sorting easier.
tl;dr:Phil shares lessons learned from production outages caused by misusing Redis. They highlight the importance of handling concurrency by sharding data across multiple instances, avoiding long-running operations in scripts, setting memory usage alerts, and using the appropriate Redis abstractions. Serializing objects to JSON for storage is discouraged, and understanding tradeoffs between data structures can prevent future issues.
tl;dr:(1) Aggregate other services into your app’s healthcheck. (2) Set a short timeout on healthcheck requests. (3) Set a long timeout on healthcheck requests. (4) Leave a long delay before starting healthchecks on new instances. (5) Set a low threshold on consecutive failures before turning unhealthy. (6) Set a high threshold on consecutive successes before turning health.
tl;dr:“One of my stock interview questions goes: "When picking between dependencies to use in production, what factors contribute to your decision?" I'm surprised by how often I receive an answer along the lines of "Github stars" and not much else. I happen to think Github stars is a terrible metric for selecting production code, so this post sets out my idea of a healthier framework to evaluate dependencies.”
tl;dr:(1) Keep the default value for work\_mem. (2) Push application logic into Postgres functions and procedures. (3) Use lots of triggers. (4) Use NOTIFY heavily. And more.
tl;dr:These steps are not specific to a particular language or paradigm, Phil's explains each of the following debugging steps: (1) Reproduce the bug. (2) Reproduce it again. (3) Don't reproduce it. (4) Understand the code. (5) Observe state. (6) Write down what you (think you) know. (7) Rule things out. (8) Walk the dog. (9) Rewrite a component. (10) Write a failing test case. (11) Fix it.