An idempotent POST is a concept, useful in payment API scenarios. The API provider wants to ensure that if an API call to make a payment fails during execution – such as in timeout scenarios where no discernable HTTP response is returned to the client – subsequent attempts do not result in a duplicate payment instruction submitted. Idempotency is achieved by requiring the client to submit the same instruction with an identifier that signals to the API provider that they might have seen this instruction before.

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.

I had a conversation recently involving contract testing between partners. The provider provides the contract during their ci/cd process before the deployment. The consumer will validate it and if something fails, the change is rejected and the deployment never occurs. The concept of consumers signing off and blocking deployments is very interesting as it empowers and handles the control to the consumer.

It is much easier to imagine negative consequences than the positive possibilities of a change. Humans are wired to first think about the risks as a survival trait.

Progress begets progress, which is why celebrating milestones and team culture in the form of stories and surprises that become folklore are critical. This is the stuff that keeps a team together long enough to figure it out. Without these elements of adventure, building a company or any other bold project feels like you’re on a treadmill and will be harder. https://www.linkedin.com/pulse/10-thoughts-running-leading-teams-building-products-scott-belsky/?trackingId=8qfNtJKfSI%2BhaJO9%2BNLhmg%3D%3D

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.

Observability without action is just storage Too many people store terabytes of data and call it observability https://twitter.com/boristane/status/1783842355147325494?t=5OUgcOmHIcwbGqrdIjR1Hw&s=19

Lens 1: The person In what ways (if any) might the individual be contributing to the problem? (Things like their workstyle, lack of skill, motivation, clarity.) Lens 2: You In what ways (if any) might you be contributing to the problem? (Maybe you didn’t provide feedback, didn’t set clear expectations.) Lens 3: The team/ organisation In what ways (if any) might the team/organisation/systems be contributing to the problem? (Things like interdependencies, unclear processes, conflicting priorities.