Service Consolidation Summary - Executive View

Created: 2026-02-01 Related: ADR-001, Issue #66, Full Analysis

The Challenge

The Agile Network platform currently operates across 190 repositories: - 59 active Java/Spring microservices (plus 23 archived) - 8 active BPM process repos (plus 5 archived) - 14 frontend applications (2 active monorepos + 12 legacy) - 30+ database migration repos (all deprecated) - 75+ repositories ready for immediate archival

This fragmentation creates: - High operational complexity (coordinating 100+ services) - Slow deployment cycles (need to coordinate changes across services) - Difficult onboarding (4-6 weeks for new developers) - Increased infrastructure costs - Knowledge silos (who owns what?)

The Solution

Consolidate to 15 domain-aligned services following Domain-Driven Design principles:

graph TB
    subgraph "Identity Layer"
        identity[1. identity-service]
        profile[2. profile-service]
    end

    subgraph "Content Layer"
        content[3. content-service]
        knowledge[4. knowledge-graph]
    end

    subgraph "Live Experiences"
        broadcast[5. broadcast-service]
        shoutout[6. shoutout-service]
        event[7. event-service]
    end

    subgraph "Commerce"
        commerce[8. commerce-service]
    end

    subgraph "Communication"
        notification[9. notification-service]
    end

    subgraph "Platform"
        journey[10. journey-service]
        bpm[11. bpm-service]
        gateway[12. api-gateway]
    end

    subgraph "Operations"
        admin[13. admin-service]
        analytics[14. analytics-service]
        config[15. config-service]
    end

    style identity fill:#e1f5ff
    style profile fill:#e1f5ff
    style content fill:#fff4e1
    style knowledge fill:#fff4e1
    style broadcast fill:#ffe1f5
    style shoutout fill:#ffe1f5
    style event fill:#ffe1f5
    style commerce fill:#e1ffe1
    style notification fill:#f5e1ff
    style journey fill:#f0f0f0
    style bpm fill:#f0f0f0
    style gateway fill:#f0f0f0
    style admin fill:#ffe1e1
    style analytics fill:#ffe1e1
    style config fill:#ffe1e1

Impact Summary

Repository Distribution

Current State

Consolidation Plan

pie title "Repository Disposition"
    "Keep Active (35)" : 35
    "Archive Immediately (75)" : 75
    "Consolidate to Nexgen (42 services)" : 42
    "Low Activity - Evaluate (20)" : 20

Consolidation Roadmap

Phase 1: Foundation (Months 1-3)

• config-service
• identity-service
• api-gateway

Goal: Foundational services enabling gradual migration

Phase 2: Low-Risk (Months 3-6)

• journey-service
• shoutout-service
• event-service
• analytics-service

Goal: Build confidence with non-critical services

Phase 3: Core Domain (Months 6-12)

• profile-service (8 services consolidated)
• notification-service (11 services consolidated)
• content-service (10 services consolidated)

Goal: Migrate majority of services

Phase 4: Revenue Critical (Months 9-15)

• commerce-service (8 services, Stripe/Dwolla)
• broadcast-service (6 services, Mux/Jitsi)

Goal: Zero-downtime migration of revenue services

Phase 5: Knowledge & Orchestration (Months 12-18)

• knowledge-graph
• bpm-service
• admin-service

Goal: Complete complex integrations

Phase 6: Cleanup (Months 18-20)

• Archive 75+ legacy repos
• Decommission old infrastructure
• Knowledge transfer

Goal: Clean slate, modern architecture

Top 15 Services by Consolidation Size

Archive Candidates (75 Repos)

By Category

pie title "Archive Candidates by Type"
    "Services (32)" : 32
    "Database Repos (30)" : 30
    "Frontend Apps (7)" : 7
    "BPM (5)" : 5
    "POCs (3)" : 3
    "Libraries (2)" : 2
    "Other (15)" : 15

Top 10 Largest Archives (by LOC)

1. peeq-documentation (598,511 LOC) - Markdown docs (2022)
2. peeq-fan-ionic (637,355 LOC) - Legacy mobile (2022)
3. peeq-fan-fe (648,650 LOC) - Legacy frontend (2023)
4. peeq-meetandgreet-for-iOS (545,682 LOC) - iOS app (2021)
5. peeq-load (499,961 LOC) - Load testing (2022)
6. peeq-kibana (359,770 LOC) - Custom Kibana (2021)
7. peeq-keycloak-archive (357,466 LOC) - Old Keycloak (2022)
8. peeq-conference (186,249 LOC) - DO NOT ARCHIVE (active, migrate to broadcast-service)
9. peeq-broadcast-query (64,468 LOC) - Deprecated query service (2021)
10. peeq-sandbox (67,899 LOC) - Sandbox environment (2022)

Total LOC to Archive: ~3.8 million lines (60% of codebase)

Technology Modernization

Current State (Legacy)

• Java 11-17 (mixed versions)
• Spring Boot 2.x - 3.x (mixed)
• PostgreSQL 12-14 (mixed)
• RabbitMQ messaging
• Elasticsearch 7.x
• Camunda 7.x

Target State (Nexgen)

• Java 17 LTS (standardized)
• Spring Boot 3.2+ (latest)
• PostgreSQL 15+ (unified)
• Kafka 3.x (event streaming)
• Elasticsearch 8.x (search)
• Camunda 8.x (cloud-native BPM)
• GraphQL Federation (unified API)
• OpenTelemetry (observability)

Risk Mitigation

High-Risk Services

Quality Gates

Every service migration requires: - [ ] 100% integration test coverage - [ ] Contract tests with dependencies - [ ] Load testing (same or better performance) - [ ] Security scanning (no new vulnerabilities) - [ ] Parallel run (2+ weeks for critical services) - [ ] Rollback plan documented and tested

Success Criteria

Technical Metrics

• 15 services deployed and operational
• <100ms P95 API response time
• >80% code coverage
• Zero critical security vulnerabilities
• 99.9% uptime for revenue services

Business Metrics

• Zero revenue impact during migration
• 99%+ payment success rate
• 99.9% broadcast uptime
• <100ms search response time
• 1-2 week developer onboarding

Operational Metrics

• Daily deployments per service
• <30 minute MTTR (mean time to recovery)
• 40% infrastructure cost reduction
• 75+ repos archived
• Complete documentation and runbooks

Investment Required

Team Composition (Recommended)

• Migration Tiger Team (6-8 engineers)

  • 2 Senior Architects
  • 4-6 Senior/Staff Engineers
  • 1 SRE/DevOps Lead

• Duration: 18-20 months (phased approach)

• Parallel Work Streams:

  • Stream 1: Foundation & Low-Risk (3 engineers)
  • Stream 2: Core Domain (3 engineers)
  • Stream 3: Revenue Critical (2 engineers + architect)

Alternative Approaches

Recommendation: Phased approach balances risk, cost, and business continuity.

Next Steps

Week 1-2 (Immediate)

1. Socialize analysis with engineering leadership
2. Form migration tiger team
3. Create Phase 1 detailed plan
4. Set up nexgen monorepo structure
5. Define API contracts for first 3 services

Month 1

1. Implement config-service
2. Begin identity-service consolidation
3. Set up GraphQL gateway POC
4. Archive first 20 deprecated repos
5. Establish observability baseline

Month 2-3

1. Complete Phase 1 (Foundation)
2. Begin Phase 2 (Low-Risk Services)
3. Archive 30 more deprecated repos
4. Establish SRE practices

Month 6

1. Phase 2 complete (4 new services)
2. Phase 3 in progress (core domain)
3. Lessons learned session
4. Adjust timeline if needed

Questions & Answers

Q: Why not a monolith? A: 15 services provide domain isolation, independent deployability, and team autonomy while avoiding microservice complexity.

Q: Why consolidate instead of rewrite? A: Consolidation preserves business logic and reduces risk. We modernize incrementally while maintaining functionality.

Q: What about existing data? A: Data migration is included in each phase. We use blue-green deployments and parallel runs to ensure zero data loss.

Q: Can we go faster? A: Yes, with more resources (12+ engineers). However, faster increases risk and coordination overhead.

Q: What if we don’t consolidate? A: Continued operational complexity, slower feature velocity, higher costs, and technical debt accumulation.

For detailed analysis, see: Service Consolidation Analysis

Related ADRs: ADR-001 (Service Consolidation Strategy)

Related Issues: #66 (Service Consolidation Planning)