The latest articles on DEV Community by Kacper Góra (@kacper_gra_918cd2db67968). https://dev.to/kacper_gra_918cd2db67968 https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F3960953%2Fc05d6754-8441-4fce-b52e-2d236d3828b0.png https://dev.to/kacper_gra_918cd2db67968 en Kacper Góra Sun, 31 May 2026 09:58:01 +0000 https://dev.to/kacper_gra_918cd2db67968/what-ddia-taught-me-about-reliability-59d8 https://dev.to/kacper_gra_918cd2db67968/what-ddia-taught-me-about-reliability-59d8 <p>I used to think a reliable system was simply one that doesn't crash.</p> <p>The book challenges that from the first pages.</p> <p>Failures are expected. Databases go down. Networks fail. Third-party APIs stop responding.<br> What matters is not whether failures happen — it's how the system behaves when they do.</p> <p>This hit me immediately when I thought about a service instance I've been working with.</p> <p>If it suddenly became unavailable — what would happen?<br> Would the app degrade gracefully, serving cached data or a fallback?<br> Or would the entire request chain fail?</p> <p>The honest answer: I hadn't thought about it carefully enough.</p> <p>Key takeaway from chapter 1:</p> <p>Reliability is not about preventing every failure.<br> It's about designing systems that continue operating despite them.</p> <p>Hardware faults, software errors, human mistakes — they're not edge cases.<br> They're the default state you design around.</p> <h1> systemdesign #softwaredevelopment #ddia #learninpublic </h1> architecture distributedsystems sre systemdesign