Add Phased Migration Plan: Monolith-to-Microservices Decomposition

[devin-ai-integration]

Add Phased Migration Plan: Monolith-to-Microservices Decomposition

Summary

Adds a comprehensive technical design document (docs/microservices-migration-plan.md) outlining a 22-week, 6-phase Strangler Fig migration to decompose the FTGO monolith into four independent microservices (Consumer, Restaurant, Delivery, Order).

The document covers:

• Current state analysis with specific coupling points traced to actual source files (e.g., OrderService.java direct dependency on ConsumerService, CourierRepository)
• Target architecture with database-per-service, Kafka event bus, API Gateway routing
• Communication patterns replacing synchronous cross-domain calls: choreography-based saga for order creation, event-driven delivery scheduling
• Security strategy (OAuth2/JWT via Keycloak — currently absent from the monolith)
• Data strategy for FK elimination, per-service Flyway migrations, dual-write/backfill approach
• Infrastructure requirements (Kafka, Spring Cloud Gateway, Keycloak, observability stack)
• Phase-by-phase extraction plan with exit criteria, rollback strategy, and dependency removal sequences

No code changes — documentation only.

Review & Testing Checklist for Human

• Verify the Spring Boot 2.0.3 → 3.2.x upgrade is adequately scoped. Appendix A lists this under Phase 0, but the Phase 0 task table does not include it as a line item. This is a major migration (Java 8→17+, javax.*→jakarta.*, Spring Security rewrite) that could add 2-4 weeks and should be explicitly planned or called out as a prerequisite.
• Validate the choreography saga design for order creation (Section 5.2). This introduces a new PENDING order state and eventual consistency — orders are no longer synchronously validated. Confirm this behavioral change is acceptable for your clients/frontend.
• Review the FK elimination strategy (Section 7.2). Cross-service foreign keys (orders.restaurant_id, orders.assigned_courier_id, courier_actions.order_id) become plain BIGINT columns with no referential integrity enforcement. Confirm application-level consistency checks and Kafka event guarantees are sufficient for your data integrity requirements.
• Sanity-check timeline estimates against team size and Kafka/event-driven experience. The risk register flags "team unfamiliarity with event-driven patterns" as high likelihood. If accurate, Phase 1 (first extraction) may take longer than 3 weeks.
• Confirm technology choices align with organizational standards (Keycloak vs. Auth0, Kafka vs. RabbitMQ, Unleash vs. LaunchDarkly, ELK vs. existing logging infra).

Notes

• Requested by: @mbatchelor81
• Link to Devin run

[devin-ai-integration]

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

• Address comments on this PR. Add '(aside)' to your comment to have me ignore it.
• Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

• Disable automatic comment and CI monitoring