Skip to content
ExponaBLOG
Series · Day 100 of 100

Engineering Craft

  1. 01
    5.5 years, 6 industries, one lesson in Engineering Craft
    E-commerce, transportation, tourism, trading, CRM and personalization — the stack changed every time. The problems didn't.
  2. 02
    A framework for system design interviews for production
    The same six steps I use for real designs and interviews.
  3. 03
    Back-of-the-envelope estimation: lessons from production
    Rough numbers prevent expensive architecture mistakes.
  4. 04
    Load balancing, explained simply: lessons from production
    How one server becomes many without users noticing.
  5. 05
    Scale up or scale out: a practical guide for developers
    Bigger machines or more machines — and when each wins.
  6. 06
    Where to cache: browser to database in Engineering Craft
    Every layer can cache. Each has a different cost of being wrong.
  7. 07
    Database indexes: a mental model — a step-by-step guide
    The highest-return backend skill I know.
  8. 08
    SQL or NoSQL: choosing a database — a step-by-step guide
    Pick by access patterns and consistency needs, not by trend.
  9. 09
    Read replicas: the fine print — best practices explained
    Free read scaling — with one gotcha that bites everyone.
  10. 10
    Database sharding explained: what developers should know
    What to do when one database is no longer enough.
  11. 11
    Consistent hashing in one minute: lessons from production
    Add or remove servers without reshuffling everything.
  12. 12
    CAP and PACELC without the jargon: a step-by-step guide
    What distributed databases really trade off.
  13. 13
    Strong vs eventual consistency: best practices explained
    Not every piece of data needs to be correct instantly.
  14. 14
    Design a URL shortener: a practical guide for developers
    A small problem with every core system design concept inside.
  15. 15
    Generating unique IDs at scale: best practices explained
    Auto-increment doesn't survive distributed systems.
  16. 16
    Design a rate limiter: a practical guide for developers
    Protect APIs from abuse and accidental overload.
  17. 17
    Idempotency: the API property nobody teaches in practice
    Networks retry. Users double-click. Your API must not double-charge.
  18. 18
    Design a news feed: a practical Engineering Craft guide
    Fan-out on write, fan-out on read, and the hybrid that wins.
  19. 19
    Webhooks that don't lose data: best practices explained
    Lessons from Meta Lead Ads, Shopify and payment gateways.
  20. 20
    Design a ride-hailing backend: best practices explained
    What I learned building live tracking and dispatch.
  21. 21
    Geospatial queries in practice: best practices explained
    Finding nearby drivers, stores or venues efficiently.
  22. 22
    Design an e-commerce checkout: best practices explained
    Where reliability directly equals revenue.
  23. 23
    Preventing overselling: a practical guide for developers
    Two customers, one item left.
  24. 24
    Designing multi-tenant SaaS: what developers should know
    Choices I made building real multi-tenant products.
  25. 25
    Monolith first: the honest default in Engineering Craft
    Most products should start as a well-structured monolith.
  26. 26
    The hidden costs of microservices: a step-by-step guide
    What the architecture diagrams don't show.
  27. 27
    Find service boundaries in the business, explained simply
    Split by business capability, not by technical layer.
  28. 28
    API design principles I follow: best practices explained
    Consistent APIs save every client team time.
  29. 29
    HTTP status codes that matter: best practices explained
    Ten codes cover almost every API response.
  30. 30
    REST vs GraphQL vs gRPC for Engineering Craft developers
    Three API styles and where each shines.
  31. 31
    Backward-compatible API changes: lessons from production
    Rules that keep clients working.
  32. 32
    Designing a search feature: patterns, pitfalls and fixes
    From a LIKE query to a search engine.
  33. 33
    Full-text search in PostgreSQL: best practices explained
    Good search without another system.
  34. 34
    Observability: logs, metrics and traces, explained simply
    Three signals that answer different questions.
  35. 35
    SLIs, SLOs and error budgets: what developers should know
    Reliability targets the business can understand.
  36. 36
    Incident response at 3 AM: practical tips and trade-offs
    What a calm incident looks like.
  37. 37
    Blameless postmortems: a practical guide for developers
    Ask what failed in the system, not who failed.
  38. 38
    Failure is a feature: designing resilient systems explained
    Assume every dependency will fail — then plan for it.
  39. 39
    Graceful degradation in practice: lessons from production
    When something breaks, break a little — not everything.
  40. 40
    Zero-downtime schema changes, step by step: a deep dive
    Change the database while traffic keeps flowing.
  41. 41
    Dark launches: ship code, release later, explained simply
    Deploy anytime. Release when ready.
  42. 42
    Anatomy of a solid CI/CD pipeline: a step-by-step guide
    Every green checkmark is a promise.
  43. 43
    Trunk-based development for Engineering Craft developers
    Short-lived branches, frequent merges, fewer conflicts.
  44. 44
    A Git workflow for teams: a hands-on guide for engineers
    Conventions that keep history useful.
  45. 45
    Write commit messages for future you in Engineering Craft
    A good message explains why, not just what.
  46. 46
    How I review code as a tech lead: lessons from production
    Reviews are for quality, knowledge sharing and mentoring.
  47. 47
    Small pull requests win for Engineering Craft developers
    A 200-line PR gets a review. A 2,000-line PR gets an approval.
  48. 48
    Technical debt: talking about it and paying it down
    Debt is a tool. Unmanaged debt is a tax.
  49. 49
    Keep a tech debt register: practical tips and trade-offs
    Invisible debt never gets prioritized.
  50. 50
    Architecture decision records: best practices explained
    Write down why, so nobody has to guess later.