Reading an RFC Alternatives Considered Section — Comprehension Exercises

RFC-0047: Alternatives Considered (Section 6) Before adopting the proposed approach (Approach B, request-response), three alternatives were evaluated and rejected. Option A — Status quo (no migration) Maintaining the current monolithic deployment was considered. This was rejected because the problem (47-minute deployments, 94-minute test runs) will worsen as the codebase grows. Doing nothing is an active choice to accept increasing toil and reduced delivery speed. This option was rejected due to unacceptable long-term cost. Option B — Full event-driven architecture from day one A complete migration to event-driven messaging for all services was considered. This was rejected due to operational overhead: our team has no experience operating a message broker at production scale, and adopting one for all services simultaneously would require a training investment estimated at 6–8 weeks before any migration work could begin. The risk profile was considered too high for an initial migration. Option C — Third-party deployment orchestration platform Using an external SaaS platform to manage our deployment pipeline was evaluated. This was rejected due to vendor lock-in risk: the platform would become a critical dependency for our entire delivery process. Additionally, the platform's pricing model would exceed our infrastructure budget at current scale. The adopted option (Approach B, synchronous request-response for the initial three-service extraction) was selected as the lowest-risk path to delivering measurable improvement within the current quarter.