Design decisions
When architecting a system, it is inevitable to make certain high-level design decisions.
Some of these decisions, if they’re wrong, can lead to the re-architecturing and re-writing of the whole system some months later, so there is an incentive to keep things rather generic. On the other hand, trying to make system too generic is just another recipe to disaster (usually expressed in terms of missed deadlines and unmanageable code).
IT Hares try to describe certain not-so-obvious architectural decisions, and some considerations which should be kept in mind while making them.
Unchecked Exceptions for C++
June 7, 2018 by • “No Bugs” Bunny
Quote:
‘unchecked’ std::errors are treated as ‘something which should never ever happen, but in practice MAY occur as a result of potentially-recoverable bug'
Another Quote:
Failing-Fast does NOT mean we should necessarily Fail-Hard(!). In certain (production!) cases, Failing-Fast-AND-Soft IS a substantially better alternative.
Filed under: On.System ArchitectureDesign decisionsOn.ProgrammingProgramming LanguagesOn.DevelopmentDevelopment Philosophy
The Importance of Back-of-Envelope Estimates
August 8, 2017 by • “No Bugs” Bunny
Quote:
trying to optimize out a 3e-7 performance hit is very rarely worth the trouble.
Another Quote:
With 4S/4U boxes having typical MTBFs of 3–5 years, the next question we should ask ourselves, is “Hey, will we really be able to write software which crashes much more rarely than that?”
Filed under: On.System ArchitectureRequirement analysisDesign decisions
Read moreGradual OLTP DB Development - from Zero to 10 Billion Transactions per Year and Beyond
December 13, 2016 by • “No Bugs” Bunny
Quote:
to make an efficient representation usable for OLAP – we need to modify our data on its way to OLAP replicas
Another Quote:
Each of the DB Server Apps is a replica master, but all replica targets are within the same Replica DB
Filed under: Book: D&D of MOGs1st beta of Vol. IV-VIOn.System ArchitectureDesign decisionsDistributed systems(Re)Actors
Read moreRepresenting The Same Data Structure in SQL and NoSQL (from Classical Codd-style SQL to Key-Value NoSQL with SQL-with-XML and Structured NoSQL in between)
December 5, 2016 by • “No Bugs” Bunny
Quote:
while duplication MAY indeed improve performance – undue duplication also MAY hit performance pretty badly
Another Quote:
NoSQL will usually call for another denormalisation on top of what we’ve described above for SQL-with-XML.
Filed under: Book: D&D of MOGs1st beta of Vol. IV-VIOn.System ArchitectureDesign decisions
Read more