Solution Architecture

Capability fit means testing whether a tool actually solves your specific problem in practice, not just matching feature names on a list. A checklist can say 'yes' to a feature while the real behavior, limits, or edge cases don't match what you need.

Capex is money spent upfront to buy something you own long-term, like servers. Opex is ongoing spending to run things day to day, like a monthly cloud bill. Cloud turns a big upfront hardware purchase into a recurring subscription-like cost.

Sync: caller waits for an instant answer, like a phone call. Async: caller sends a message and moves on, checking back later, like a letter. Sync is simple but ties your uptime to the other side; async is more resilient but harder to reason about.

SLI is what you actually measure (e.g., % of successful requests). SLO is the internal goal for that measurement (e.g., 99.9%). SLA is the external, often contractual, promise to customers — usually set looser than the SLO so you have margin.

Functional requirements describe what the system must do, e.g. 'let a user reset their password.' Non-functional requirements describe how well it must do it, e.g. 'password reset must respond in under 2 seconds for 99% of requests.'

Because comparing choices lets you see costs and risks you'd miss with just one idea, and it lets stakeholders make an informed pick instead of trusting a single opinion.

Different people care about different things. A sponsor wants to know cost, risk, and business value; an engineer wants to know how the system's pieces talk to each other in detail. One diagram can't do both jobs well.

RFI asks vendors 'tell us about yourselves and your product' to narrow a long list. RFP asks the shortlisted vendors 'here's exactly what we need, give us a formal, priced proposal.' RFI happens first so you don't waste a detailed RFP on unqualified vendors.

They edited the software's core parts directly instead of using the vendor's safe, supported ways to customize it, like plugins or settings. The next update assumed nobody touched the core, so it broke. Use only supported extension points instead.

Six weeks isn't the real cost. After launch, someone must keep fixing and running it forever, and those engineers could've built something else instead. Compare the full years-long cost, including that lost opportunity, not just build time.

Look past star counts at things like how often it's updated, how fast bugs get fixed, how many people maintain it, and whether real companies use it in production. A popular but abandoned project is riskier than a smaller, active one.

List every cost each option will cause over the same time period — not just the price tag, but also setup, running, and people costs — then add them up and compare like for like over the same number of years.

A contract is the agreed shape of requests and responses between two systems - like a form both sides fill out the same way. To change it safely, add new optional fields instead of removing or renaming old ones, so old callers keep working.

99.95% means about 4.4 hours of downtime allowed per year. To hit that you typically need redundancy (multiple instances/zones), automatic failover, health checks, no single point of failure, and enough capacity headroom to survive losing a node without falling over.

Talk to each group separately first (interviews, workshops) to understand their real needs, then bring the conflicting groups together with a shared list of options and trade-offs so they negotiate and agree, usually prioritizing by business impact, instead of the architect silently picking a side.

List the things that matter (like cost and speed), give each a weight for importance, score each option on each thing, multiply and add up the scores, and the highest total is the suggested winner -- but you still sanity-check it, because the weights themselves were a judgment call.

Translate the technical trade-off into things they care about: cost, time, risk, and what the business gets or gives up with each option. Give a clear recommendation, not just a list of pros and cons.

You list the things that matter (price, features, support...), give each a weight based on importance, score every vendor on each item, multiply and add up. The misuse: picking the weights AFTER seeing the favorite vendor score well, to make the math match a decision already made.

Lock-in has several forms: data trapped in the vendor's format, systems wired to their specific APIs, staff knowing only that vendor's tools, or a contract penalizing exit. Reduce it by negotiating data export and standard interfaces before signing.

Lock-in happens when a product uses so many of a vendor's unique features that switching away becomes expensive or impossible. You reduce it by using standard interfaces where you can, isolating vendor-specific code behind your own abstraction layer, and keeping your data in portable formats.

FinOps means treating cloud spend like a thing you actively manage, not a surprise bill. You estimate cost per unit of usage before building, label every resource so you know which team or feature caused a cost, show teams their own spend so they feel responsible for it, and commit to steady baseline capacity in advance to get a discount.

Pick request-reply when a consumer needs the answer right now to keep working, like a checkout screen. Pick events when a consumer just needs to know 'something changed' and can react later, like analytics or recommendations. Using events everywhere adds delay and complexity where you didn't need it.

It pushes you toward stateless services that can scale horizontally, autoscaling on real metrics, partitioning/sharding data stores so no single DB instance is the ceiling, and caching/async processing to cut load on the bottleneck. You validate it with load testing at the target scale, not by assuming the design works.

It's a table linking every requirement to the design, code, and tests that satisfy it, so you can prove nothing important was missed, silently dropped, or built without ever being verified. Skip it and requirements quietly disappear or get marked 'done' without proof they actually work.

A good rationale write-up explains what you compared, what mattered most and why, and what you'd have to see change to reconsider -- so months later anyone can read it and understand the decision without you having to remember or re-explain it from memory.

Get both people talking about the actual risk and the actual cost of delay, not just their positions. Find a middle option, like phasing in the strongest protection first, and get someone with the authority to accept the trade-off to make the call.

Lock-in isn't just a feeling - it's specific things like your data being stuck in a proprietary format, custom code that only works with that vendor's API, or contract penalties for leaving. An exit strategy written down before you sign lists exactly how you'd get your data out, how long it would take, and what it would cost, so you're not stuck figuring it out under pressure later.

Give every vendor the same test, same data, same amount of help, and same success criteria decided beforehand - otherwise whoever gets more attention or an easier task wins unfairly. POCs often look great because vendors hand-hold and use small clean data, which doesn't reflect real production scale, messy data, or the support you'll get after you've already paid.

Some licenses (MIT, Apache) let you use code freely in a closed-source product. Others (GPL, AGPL) can require you to release your own product's source code, or at least the parts that link to that library, under the same license if you distribute or run it as a service.