Architecture organizing model https://architectelevator.com/architecture/organizing-architecture/

When you buy integration tools, you are agreeing to build the actual integration itself. What you are buying is a promise that the integration can be solved more efficiently and more simply than using a general purpose language

APIs are Forever When a social media post graces the internet, it leaves a permanent impression on web users thereafter — that’s to say, it remains visible and “on the record” until the end of days. A similar thing happens with AWS’ APIs, though those outcomes are more intentional. When AWS introduces an API, Vogels believes that this API must remain ever-present and largely unchanged. Once companies fundamentally change or remove a longstanding API from general availability, business customers who’ve built atop it will suffer.

A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched to make it work. You have to start over with a simple working system.

Use autoscaling for traffic spikes design for scalability from the start plan for and implement fault tolerance prioritize horizontal scaling for scalability implement data partitioning and sharding use data lakes for analytics and reporting employ CDNs for global latency reduction make operations idempotent for simplicity use event-driven architecture for flexibility employ blob/object storage for media files embrace tradeoffs; perfection is unattainable implement Data Replication and Redundancy Implement rate Limiting for system protection use a read-through cache for read-heavy apps utilize write-through cache for write-heavy apps opt for NoSQL Databases for unstructured data use Heartbeat Mechanisms for failure detection adopt WebSockets for real-time communication employ Database Sharding for horizontal scaling clearly define system use cases and constraints consider microservices for flexibility and scalability design for flexibility; expect requirements to evolve utilize Database Indexing for efficient data retrieval understand requirements thoroughly before designing Utilize asynchronous processing for background tasks consider denormalizing databases for read-heavy tasks avoid over-engineering; add functionality only as needed prefer SQL Databases for structured data and transactions use Load Balancers for high availability and traffic distribution consider message queues for asynchronous communication

Nemawashi (根回し) in Japanese means an informal process of quietly laying the foundation for some proposed change or project, by talking to the people concerned, gathering support and feedback, and so forth Put more effort and time into searching for and involving people who either will have strong opinions about a large decision or will be affected by that large decision The Rule: anyone can make an architectural decision. The Qualifier: before making the decision, the decision-taker must consult two groups: The first is everyone who will be meaningfully affected by the decision.