Five Koans of Software Architecture
bellmar.medium.com
Five Koans of Software Architecture
1–10 of 16 posts
Re: Five Koans of Software Architecture
#2> are you going to be on call for this
When does a call at 3am involve an architectural decision or change? It should never come that far.
Re: Five Koans of Software Architecture
#3When did “koan” become a synonym for “aphorism”?
Re: Five Koans of Software Architecture
#4> are you going to be on call for this When does a call at 3am involve an architectural decision or change? It should never come that far.
It’s a variant of the old “Would you bet your career on this?”:
Re: Five Koans of Software Architecture
#5> are you going to be on call for this When does a call at 3am involve an architectural decision or change? It should never come that far.
[deleted]
Re: Five Koans of Software Architecture
#6When did “koan” become a synonym for “aphorism”?
When everyone started believing in themselves as part-time Zen masters after watching a TED talk video on YouTube.
Re: Five Koans of Software Architecture
#7When did “koan” become a synonym for “aphorism”?
That's the real koan.
Re: Five Koans of Software Architecture
#8> are you going to be on call for this When does a call at 3am involve an architectural decision or change? It should never come that far.
I've been the victim of this, a producer consumer system with a single index file using some variant of a heap.
For each incoming request the producer;
locked the file, read the heap from the file, added the value to the heap, then wrote it back and unlocked it.
For each consumer thread, the thread did the reverse. It was setup with threads created by incoming requests, and a threadpool of 128 threads for the consumer.
This worked seamlessly until one day, at 3am PST, a flood of requests came in and the index file grew to ~4mb, and everything ground to a halt.
The legend of the architecture was a senior engineer did this on a weekend, then a month later left the company.
Re: Five Koans of Software Architecture
#9graph dbs are just easily traversable joins of all many-to-many tables. although they have way less tooling in most ecosystems to support them (e.g. REST API was tough to do), they are extremely powerful [realizing i should write a post]. so, i would only use the entities i was modeling were natural graphs: chemistry, supply chain, network.
neomodel is a fantastic python ORM for a neo4j: https://neomodel.readthedocs.io/en/latest/
Re: Five Koans of Software Architecture
#10> are you going to be on call for this When does a call at 3am involve an architectural decision or change? It should never come that far.
I think, you are misreading it.
It isn't about making an architectural design decision / change at 3am, but someone has to live with the consequences of such a design decision and fix something in some way or another at 3am in the morning.
I.e. you could go with a clustered db setup which is supposedly HA, or a classical single instance DB...
The point here is, whoever has to get up at 3am to fix a potential catastrophic failure in the setup should have a say in it.