50 shades of system design
Tradeoffs behind designing scalable, reliable systems
Highlights
Passages saved from the original.
Summary AI-generated
Summarised by an AI assistant when this source was saved. Double-check against the original.
In summary, the most interesting aspect is that system design is not about finding a \"best\" architecture, but rather the strategic navigation of inevitable tradeoffs between competing technical constraints.
- System design is fundamentally about making the right tradeoffs for a specific workload rather than seeking a perfect architecture.
- Balance critical tensions such as latency vs. throughput, consistency vs. availability, and normalization vs. denormalization.
- Choose infrastructure (e.g., monolith vs. microservices, SQL vs. NoSQL) based on whether you prioritize operational simplicity or independent scalability.
- Manage reliability and failure modes using tools like circuit breakers, load shedding, and idempotency to protect system stability.
Notes this inspired
- Saga choreography vs saga orchestrationGrowing
Either each service triggers the next one, or there is an orchestrator managing the whole thing. Queen was an orchestrator whereas in PIMS, it was choreography style, retriever triggers transformer, etc.
- Batch processing vs stream processingGrowing
In old existing product data, it was stream processing, processing one spider item at a time. whereas in dogs, it was batch processing, processing 'big' sqlite files.
- API DesignSeedling
- API retriesGrowing
Good to handle the odd error. Beware of overloading already failing services with even more load. API Circuit breakers will help.
- API Circuit breakersGrowing
Failing fast is better than failing slow. Circuit breakers allows not calling services that are broken so that they're not overloaded. Half open allows letting a few requests through to see if…
- API short vs long timeoutsGrowing
Set long timeouts intentionally, services should be fast, unless it is purposefully (can't do otherwise) slow.
Also cited by
- REST vs GraphQLGrowing
When is GraphQL is a good idea? When flexibility of what data to retrieve is important, but it is possibly rarely worth the overhead.