Make payments, emails, and state changes idempotent. How: Use unique request IDs. If the ID is already processed then return “success” without doing it again. One rule that prevents millions in losses. #100DaysOfArchitecture

Strong consistency required in money, seats, inventory, usernames Eventually consistent is OK in likes, views, recommendations, news feed Write this table on Day 1. It decides your database, queues, and service boundaries for the next few years. #100DaysOfArchitecture

Write the runbook before you write the code. “One-click rollback” and “how to restore money” are the only features that would matter when shit hits the fan. #100DaysOfArchitecture

Good errors tell exactly: - What failed - Why it matters - What the user can do next Vague errors = lost money lost trust. Make errors part of the design, not an afterthought. #100DaysOfArchitecture

Real architecture skill isn’t adding new services. It’s having the courage to kill the old ones that everyone is afraid to touch. In order words break that codebase even if it still manages to work Delete first then Design a second one. #100DaysOfArchitecture

If a change takes more than 15 minutes from commit to live then your architecture is broken, no matter how many microservices you have. Deploy speed is the ultimate test of any architecture. #100DaysOfArchitecture

Database choice, data model, consistency rules, transaction boundaries = your entire architecture. Decide these on Day 1 based on your deadly decisions (Day 11), not on what’s trendy. #100DaysOfArchitecture

Result: - 3 am outage → nobody knows why - Cloud bill jumps ₦45M → discovered 3 months late - Stakeholders lose trust forever Observability is not a “nice-to-have”. It is the first requirement, not the last. #100DaysOfArchitecture

Examples: “Can we reverse a payout?” “Can two users book the same seat?” That single decision forces your architecture (CORS, sagas, locks, etc.). Find the deadly decision first. #100DaysOfArchitecture