東風
232 posts
Do not use UUID as your primary key by default, use BIGINT identity for OLTP (smaller indexes, faster joins) and add UUID only when you need cross-system uniqueness.
Do not use OFFSET pagination on big tables, use keyset pagination (WHERE id > last_id ORDER BY id LIMIT n) with a stable index.
Do not use SELECT * in hot paths, use narrow selects (only columns you need) + cover with the right index.
Do not use COUNT(*) on a giant table for UX counters, use approx counts / cached counters / rollups depending on accuracy needs.
Do not use JSONB for everything, use proper relational columns for fields you filter/sort on, keep JSONB for truly flexible metadata.
Do not use EAV schemas (“key/value tables”) for core entities, use normal forms + migrations (EAV becomes un-indexable pain).
Do not use “one index per query” guesswork, use EXPLAIN (ANALYZE, BUFFERS) and index what your workload actually does.
Do not use big multi-table joins for dashboards, use ETL/CDC into OLAP (ClickHouse/Druid/BigQuery) and query there.
Do not use sync writes to multiple DBs, use outbox pattern + CDC so data movement is replayable and consistent.
Do not use triggers for business logic, use application-level writes (triggers become invisible dependencies and debugging hell).
Do not use serializable isolation everywhere, use the lowest isolation that meets correctness + explicit locks only where needed.
Do not use long transactions, use short transactions (long txns = bloat, locks, vacuum issues, replica lag).
Do not use “DB is slow, add replicas” first, use query shaping + indexes + connection pool sanity + caching (in that order).
Do not use “just increase max_connections”, use pooling (PgBouncer) + right-sized pools (too many connections kills throughput).
Do not use hot partitions / single shard keys, use evenly distributed keys or composite sharding to avoid hotspots.
Do not use ad-hoc migrations in prod, use online migration patterns (expand/contract, backfills, dual writes when needed).
Do not use no backups because “we have replicas”, use tested restores + PITR (a replica is not a backup).
Do not use “we’ll clean it later” retention, use TTL/partition drop for time-series and audit logs (deletes don’t scale).
Do not use indexing without considering writes, use the minimum indexes that hit your p95 (each index is a write tax).
Do not use text search via LIKE '%foo%', use proper search (Postgres GIN/tsvector) or a search engine when ranking matters.
Do not use cache as truth, use DB as source of truth and caches as derived state with invalidation strategy.
Abhishek Singh@0xlelouch_
Do not use REST + polling + “is it done?” endpoints, use async jobs + webhook/callbacks + idempotency keys. Do not use cron + bash scripts + hope, use a workflow engine (Temporal / Argo Workflows) with retries, timeouts, and history. Do not use “logs in prod” debugging, use distributed tracing + correlation IDs + structured logs. Do not use manual SSH fixes on servers, use immutable deployments (containers/images) + GitOps. Do not use one giant DB for everything, use Postgres for OLTP + a real OLAP store for analytics (ClickHouse/Druid) and keep them separate. Do not use offset pagination at scale, use cursor/keyset pagination with stable ordering. Do not use global mutexes for rate limits, use token bucket with Redis/Lua or a dedicated rate-limit service. Do not use “exactly once” promises to sleep at night, use at-least-once + dedupe keys + idempotent handlers. Do not use Kafka as a queue for retries, use DLQ + retry topics + backoff (or a real queue like SQS) depending on semantics. Do not use “cache everything” reflexively, use caching only with correctness guarantees (TTL + stampede protection + versioned keys). Do not use “one config per env” copied around, use a single config schema + typed validation + runtime reload. Do not use ad-hoc feature flags in code, use a flag service + kill switches + gradual rollouts. Do not use dashboards as your alerting system, use SLOs + error budgets + actionable alerts (not spam). Do not use “k8s will autoscale it” as capacity planning, use load tests + p95/p99 budgets + real headroom math. Do not use “JWT everywhere” blindly, use short-lived access tokens + refresh + revocation strategy (or sessions when you need instant logout). Do not use “one big microservice mesh” to fix architecture, use clear boundaries + contracts + fewer services with better ownership. Do not use “just add more replicas” for DB pressure, use query shaping + indexes + caching + read replicas (in that order).
English
