Proposals
Architecture and infrastructure change proposals
Overview
This section contains proposals for significant changes to applications, infrastructure, or architecture. Each proposal documents the rationale, impact, and implementation plan.
Active Proposals
Browse all proposals below or navigate through the sidebar.
Proposal Template
When creating a new proposal, include:
- Summary - Brief overview of the proposed change
- Rationale - Why this change is needed
- Impact - Which applications and systems are affected
- Implementation Plan - Steps to execute the proposal
- Risks - Potential issues and mitigation strategies
- Status - Draft, Under Review, Approved, Implemented, Rejected
1 - Edge Department Info Service Migration
Proposal for edge-department-info-service migration/modernization
Summary
Proposal for the migration and modernization of the edge-department-info-service.
Rationale
[To be filled in - reasons for this change]
Key benefits expected:
Affected Applications
- flux-handler-service - Django REST based web service for Department Info (opening times etc.) lookups
Impact
Services Affected
- Edge department info service
- [List additional services and dependencies]
Technical Considerations
- API compatibility with existing consumers
- Department data accuracy and synchronization
- Performance and response time requirements
- Caching strategy for department information
Data Considerations
- Department data storage and updates
- Data consistency across systems
- Data source integration
- Master data management
Implementation Plan
Phase 1: Assessment & Design
Phase 2: Development
Phase 3: Migration
Phase 4: Cutover
Risks & Mitigation
| Risk | Impact | Mitigation |
|---|
| Service disruption | High | Gradual cutover with parallel running systems |
| Department data inconsistency | High | Thorough data validation and testing |
| Performance degradation | Medium | Load testing and capacity planning |
| Integration breakage | High | Extensive integration testing before cutover |
| Data source synchronization issues | Medium | Implement robust data sync mechanisms |
Timeline
[To be determined]
Status
Current Status: Draft
History:
- 2025-12-22: Proposal created
2 - Edge Sources Service Migration
Proposal for edge-sources-service migration/modernization
Summary
Proposal for the migration and modernization of the edge-sources-service.
Rationale
[To be filled in - reasons for this change]
Key benefits expected:
Affected Applications
No applications currently associated with this proposal.
Impact
Services Affected
- Edge sources service
- [List additional services and dependencies]
Technical Considerations
- API compatibility with existing consumers
- Sources data accuracy and synchronization
- Performance and response time requirements
- Caching strategy for sources information
Data Considerations
- Sources data storage and updates
- Data consistency across systems
- Data source integration
- Master data management
Implementation Plan
Phase 1: Assessment & Design
Phase 2: Development
Phase 3: Migration
Phase 4: Cutover
Risks & Mitigation
| Risk | Impact | Mitigation |
|---|
| Service disruption | High | Gradual cutover with parallel running systems |
| Sources data inconsistency | High | Thorough data validation and testing |
| Performance degradation | Medium | Load testing and capacity planning |
| Integration breakage | High | Extensive integration testing before cutover |
| Data source synchronization issues | Medium | Implement robust data sync mechanisms |
Timeline
[To be determined]
Status
Current Status: Draft
History:
- 2025-12-22: Proposal created
3 - Migrate Applications from Elastic Beanstalk to AWS Fargate
Proposal to migrate Elastic Beanstalk-hosted applications to AWS Fargate
Summary
Proposal to migrate applications currently hosted on Elastic Beanstalk to AWS Fargate, a serverless container orchestration platform.
Rationale
[To be filled in - reasons for migrating from Elastic Beanstalk to Fargate]
Key benefits expected:
- Greater infrastructure control and flexibility
- Improved cost efficiency at scale
- Enhanced performance and resource allocation
- Better integration with AWS ecosystem
- Reduced vendor lock-in
- Improved scalability options
Affected Applications
Impact
Services Affected
- All Elastic Beanstalk-hosted applications
- [List specific applications to be migrated]
Technical Considerations
- Container image creation and registry setup (ECR)
- VPC and networking configuration
- Load balancer setup (ALB/NLB)
- Service discovery and task definitions
- Auto-scaling policies
- CI/CD pipeline modifications
- Logging and monitoring infrastructure
- Secret management (AWS Secrets Manager/Parameter Store)
Infrastructure Considerations
- Database migration (Elastic Beanstalk Postgres to RDS/Aurora)
- Redis/cache migration (Elastic Beanstalk Redis to ElastiCache)
- File storage migration (S3 integration)
- Add-on replacements and alternatives
- Domain and DNS configuration
- SSL/TLS certificate management
Data Considerations
- Database backup and migration strategy
- Data consistency during migration
- Downtime requirements
- Rollback procedures
Implementation Plan
Phase 1: Assessment & Design
Phase 2: Infrastructure Setup
Phase 3: Application Preparation
Phase 4: Data Migration
Phase 5: Testing & Validation
Phase 6: Migration & Cutover
Risks & Mitigation
| Risk | Impact | Mitigation |
|---|
| Extended downtime during migration | Critical | Plan careful cutover with blue-green deployment |
| Data loss during database migration | Critical | Multiple backups, test migrations, validation procedures |
| Application compatibility issues | High | Thorough testing in staging environment |
| Increased operational complexity | Medium | Comprehensive documentation, training, automation |
| Cost overruns | Medium | Detailed cost analysis, monitoring, right-sizing |
| Performance degradation | High | Performance testing, proper resource allocation |
| Loss of Elastic Beanstalk add-on functionality | Medium | Identify and implement AWS equivalents beforehand |
| CI/CD pipeline disruption | Medium | Test new pipelines before cutover |
Timeline
[To be determined]
Status
Current Status: Draft
History:
- 2025-12-22: Proposal created
4 - Migrate Applications from Heroku to AWS Fargate
Proposal to migrate Heroku-hosted applications to AWS Fargate
Summary
Proposal to migrate applications currently hosted on Heroku to AWS Fargate, a serverless container orchestration platform.
Rationale
[To be filled in - reasons for migrating from Heroku to Fargate]
Key benefits expected:
- Greater infrastructure control and flexibility
- Improved cost efficiency at scale
- Enhanced performance and resource allocation
- Better integration with AWS ecosystem
- Reduced vendor lock-in
- Improved scalability options
Affected Applications
Impact
Services Affected
- All Heroku-hosted applications
- [List specific applications to be migrated]
Technical Considerations
- Container image creation and registry setup (ECR)
- VPC and networking configuration
- Load balancer setup (ALB/NLB)
- Service discovery and task definitions
- Auto-scaling policies
- CI/CD pipeline modifications
- Logging and monitoring infrastructure
- Secret management (AWS Secrets Manager/Parameter Store)
Infrastructure Considerations
- Database migration (Heroku Postgres to RDS/Aurora)
- Redis/cache migration (Heroku Redis to ElastiCache)
- File storage migration (S3 integration)
- Add-on replacements and alternatives
- Domain and DNS configuration
- SSL/TLS certificate management
Data Considerations
- Database backup and migration strategy
- Data consistency during migration
- Downtime requirements
- Rollback procedures
Implementation Plan
Phase 1: Assessment & Design
Phase 2: Infrastructure Setup
Phase 3: Application Preparation
Phase 4: Data Migration
Phase 5: Testing & Validation
Phase 6: Migration & Cutover
Risks & Mitigation
| Risk | Impact | Mitigation |
|---|
| Extended downtime during migration | Critical | Plan careful cutover with blue-green deployment |
| Data loss during database migration | Critical | Multiple backups, test migrations, validation procedures |
| Application compatibility issues | High | Thorough testing in staging environment |
| Increased operational complexity | Medium | Comprehensive documentation, training, automation |
| Cost overruns | Medium | Detailed cost analysis, monitoring, right-sizing |
| Performance degradation | High | Performance testing, proper resource allocation |
| Loss of Heroku add-on functionality | Medium | Identify and implement AWS equivalents beforehand |
| CI/CD pipeline disruption | Medium | Test new pipelines before cutover |
Timeline
[To be determined]
Status
Current Status: Draft
History:
- 2025-12-22: Proposal created
5 - Migrate Applications from Heroku to Cloudflare
Proposal to migrate Heroku-hosted applications to Cloudflare platform
Summary
Proposal to migrate applications currently hosted on Heroku to Cloudflare’s edge computing platform (Workers, Pages, etc.).
Rationale
[To be filled in - reasons for migrating from Heroku to Cloudflare]
Key benefits expected:
- Edge computing with global low-latency performance
- Improved cost efficiency
- Automatic global distribution
- Built-in DDoS protection and security
- Reduced infrastructure complexity
- Better integration with Cloudflare ecosystem
- Zero cold starts (Workers)
Affected Applications
Impact
Services Affected
- All Heroku-hosted applications targeted for migration
- [List specific applications to be migrated]
Technical Considerations
- Application architecture adaptation for edge computing
- Cloudflare Workers runtime compatibility
- Request/response size limitations
- Execution time limits (CPU time constraints)
- Code bundling and module system
- API compatibility and framework support
- Stateless architecture requirements
- Cloudflare Workers vs Pages vs hybrid approach
- Database migration (D1, Durable Objects, or external)
- KV storage for caching and session data
- R2 for object storage needs
- Queue system for async processing
- Analytics and monitoring setup
- Custom domain configuration
Data Considerations
- Database compatibility and migration strategy
- Session storage and state management
- File/asset storage migration
- Data residency and compliance requirements
Implementation Plan
Phase 1: Assessment & Design
Phase 2: Development Environment Setup
Phase 3: Application Migration
Phase 4: Data Migration
Phase 5: Testing & Validation
Phase 6: Migration & Cutover
Risks & Mitigation
| Risk | Impact | Mitigation |
|---|
| Runtime compatibility issues | High | Thorough testing, identify incompatibilities early |
| CPU time limit exceeded | High | Optimize code, consider splitting workloads |
| Database performance on D1 | Medium | Evaluate alternative database solutions if needed |
| Cold start issues (if any) | Low | Workers have minimal cold starts, but monitor |
| Code refactoring complexity | High | Incremental migration, thorough testing |
| Loss of Heroku add-on functionality | Medium | Identify Cloudflare or external equivalents |
| Geographic data compliance | High | Understand Cloudflare’s data residency options |
| Vendor lock-in to Cloudflare | Medium | Abstract critical services where possible |
| Development workflow changes | Medium | Training and documentation for team |
Timeline
[To be determined]
Status
Current Status: Draft
History:
- 2025-12-22: Proposal created
6 - Migrate Exchange REST API to Serverless
Proposal to migrate exchange REST API to Exchange serverless stack
Summary
Proposal to migrate the exchange REST API to a serverless architecture using the Exchange serverless stack.
Rationale
[To be filled in - reasons for migrating to serverless]
Key benefits expected:
- Improved scalability
- Reduced operational overhead
- Cost optimization through pay-per-use model
- Enhanced deployment flexibility
Affected Applications
Impact
Services Affected
- Exchange REST API endpoints
- [List additional services]
Technical Considerations
- API contract compatibility
- Authentication/authorization changes
- Performance characteristics
- Monitoring and logging setup
Data Considerations
- Database connection management
- State management in serverless environment
- Caching strategy
Implementation Plan
Phase 1: Assessment & Design
Phase 2: Development
Phase 3: Migration
Phase 4: Cutover
Risks & Mitigation
| Risk | Impact | Mitigation |
|---|
| API downtime during migration | High | Blue-green deployment with gradual traffic shift |
| Performance degradation | Medium | Thorough load testing before cutover |
| Cold start latency | Medium | Implement provisioned concurrency for critical endpoints |
| Breaking changes to API contract | High | Maintain backward compatibility, version API |
| Increased complexity | Medium | Comprehensive documentation and runbooks |
Timeline
[To be determined]
Status
Current Status: Draft
History:
- 2025-12-22: Proposal created
7 - Migrate QAB Buy Web Services to Serverless
Proposal to migrate legacy Qab buy web services to QabBuy serverless stack
Summary
Proposal to migrate legacy Qab buy web services to a modern serverless architecture using the QabBuy serverless stack.
Rationale
[To be filled in - reasons for migrating to serverless]
Key benefits expected:
- Modernize legacy infrastructure
- Improved scalability and reliability
- Reduced maintenance burden
- Cost optimization
- Enhanced deployment practices
- Better handling of peak purchase volumes
Affected Applications
Impact
Services Affected
- QAB buy/purchase web services
- [List additional services and dependencies]
Technical Considerations
- Legacy code modernization requirements
- API compatibility with existing consumers
- Integration with payment systems
- Transaction handling in serverless environment
- Performance and response time requirements
- Error handling and retry logic
Data Considerations
- Purchase data storage and retrieval
- Transaction state management
- Database access patterns
- Data consistency requirements
- Audit logging
Implementation Plan
Phase 1: Assessment & Design
Phase 2: Development
Phase 3: Migration
Phase 4: Cutover
Risks & Mitigation
| Risk | Impact | Mitigation |
|---|
| Transaction failures during migration | Critical | Robust rollback plan, gradual cutover with monitoring |
| Payment processing issues | Critical | Extensive testing with payment systems, parallel running |
| Service disruption | High | Blue-green deployment with quick rollback capability |
| Legacy code complexity | High | Thorough documentation and refactoring plan |
| Integration breakage | High | Extensive integration testing before cutover |
| Data inconsistency | High | Transaction integrity testing, audit logging |
| Performance degradation | Medium | Load testing and capacity planning |
| Compliance issues | High | Security review and compliance validation |
Timeline
[To be determined]
Status
Current Status: Draft
History:
- 2025-12-22: Proposal created
8 - Migrate QAB Quoting Web Services to Serverless
Proposal to migrate legacy Qab quoting web services to QabQuote serverless stack
Summary
Proposal to migrate legacy Qab quoting web services to a modern serverless architecture using the QabQuote serverless stack.
Rationale
[To be filled in - reasons for migrating to serverless]
Key benefits expected:
- Modernize legacy infrastructure
- Improved scalability and reliability
- Reduced maintenance burden
- Cost optimization
- Enhanced deployment practices
Affected Applications
No applications currently associated with this proposal.
Impact
Services Affected
- QAB quoting web services
- [List additional services and dependencies]
Technical Considerations
- Legacy code modernization requirements
- API compatibility with existing consumers
- Integration points with other systems
- Performance and response time requirements
- Session management in serverless context
Data Considerations
- Database access patterns
- Quote data storage and retrieval
- State management
- Caching requirements
Implementation Plan
Phase 1: Assessment & Design
Phase 2: Development
Phase 3: Migration
Phase 4: Cutover
Risks & Mitigation
| Risk | Impact | Mitigation |
|---|
| Service disruption | High | Gradual cutover with parallel running systems |
| Legacy code complexity | High | Thorough documentation and refactoring plan |
| Integration breakage | High | Extensive integration testing before cutover |
| Performance issues | Medium | Load testing and capacity planning |
| Data inconsistency | High | Thorough testing of quote calculations |
| Loss of domain knowledge | Medium | Document business logic during migration |
Timeline
[To be determined]
Status
Current Status: Draft
History:
- 2025-12-22: Proposal created
9 - Serverless Callbacks Migration
Proposal to migrate callbacks functionality to serverless architecture
Summary
Proposal to migrate callbacks functionality to a serverless architecture.
Rationale
[To be filled in - reasons for migrating to serverless]
Key benefits expected:
- Improved scalability for callback processing
- Reduced operational overhead
- Cost optimization through pay-per-use model
- Better handling of variable callback volumes
- Enhanced reliability and retry mechanisms
Affected Applications
Impact
Services Affected
- Callback handling services
- [List additional services and dependencies]
Technical Considerations
- Webhook/callback endpoint compatibility
- Event-driven architecture implementation
- Asynchronous processing requirements
- Retry and failure handling
- Message queue integration
- Timeout and execution limits
Data Considerations
- Callback data storage and logging
- Event sourcing patterns
- Audit trail requirements
- Dead letter queue handling
Implementation Plan
Phase 1: Assessment & Design
Phase 2: Development
Phase 3: Migration
Phase 4: Cutover
Risks & Mitigation
| Risk | Impact | Mitigation |
|---|
| Callback delivery failures | High | Implement robust retry mechanisms and dead letter queues |
| Duplicate callback processing | Medium | Implement idempotency keys and deduplication |
| Cold start latency | Medium | Use provisioned concurrency for critical callbacks |
| Message loss during migration | High | Parallel processing with validation before cutover |
| Timeout issues for long-running callbacks | Medium | Design async processing patterns, evaluate timeout limits |
| Integration breakage | High | Extensive testing with all callback sources |
| Monitoring gaps | Medium | Comprehensive logging and alerting setup |
Timeline
[To be determined]
Status
Current Status: Draft
History:
- 2025-12-22: Proposal created
10 - Universal Geo Service Migration
Proposal for universal-geo-service migration/modernization
Summary
Proposal for the migration and modernization of the universal-geo-service.
Rationale
[To be filled in - reasons for this change]
Key benefits expected:
Affected Applications
Impact
Services Affected
- Universal geo service
- [List additional services and dependencies]
Technical Considerations
- API compatibility with existing consumers
- Geographic data accuracy and coverage
- Performance and response time requirements
- Caching strategy for geo lookups
Data Considerations
- Geographic data storage and updates
- Data accuracy and validation
- Third-party data sources and licensing
Implementation Plan
Phase 1: Assessment & Design
Phase 2: Development
Phase 3: Migration
Phase 4: Cutover
Risks & Mitigation
| Risk | Impact | Mitigation |
|---|
| Service disruption | High | Gradual cutover with parallel running systems |
| Geographic data accuracy issues | High | Thorough data validation and testing |
| Performance degradation | Medium | Load testing and capacity planning |
| Integration breakage | High | Extensive integration testing before cutover |
| Third-party dependency issues | Medium | Evaluate and test all external dependencies |
Timeline
[To be determined]
Status
Current Status: Draft
History:
- 2025-12-22: Proposal created
11 - Remove Fakertrail Application
Proposal to decommission the fakertrail application
Summary
Proposal to remove the fakertrail application from our infrastructure.
Rationale
[To be filled in - reasons for removing this application]
Affected Applications
Impact
Services Affected
- List services that will be impacted
- Downstream dependencies
Data Considerations
- Data migration requirements
- Backup and archival needs
Implementation Plan
Phase 1: Preparation
Phase 2: Migration
Phase 3: Decommissioning
Risks & Mitigation
| Risk | Impact | Mitigation |
|---|
| Loss of functionality | Medium | Document all features before removal |
| Data loss | High | Full backup before decommission |
| Broken integrations | Medium | Audit all integrations beforehand |
Timeline
[To be determined]
Status
Current Status: Draft
History:
- 2025-12-20: Proposal created
12 - Provider Agnostic Geo Lookup Library
Proposal for a Python library that abstracts geo lookup providers for resilience and reusability
| Status | Effort | Client Cost Saving |
|---|
| Draft | 20 | TBD |
Summary
Create a Python library that provides a provider-agnostic interface for geographic address lookup services. This library will support automatic failover between providers, ensuring service continuity
during provider outages, and can be deployed across multiple projects and platforms (DRF, Lambda).
Rationale
The Problem
On 2026-02-04, getaddress.io experienced several hours of downtime. This caused a complete failure of the quote service flow because:
- Single Provider Dependency: The geo service currently relies exclusively on getaddress.io with no fallback mechanism
- Cross-Client Impact: This single point of failure affects multiple clients (Adrian Flux, Sterling, Bikesure) and multiple product lines (EPAs, JAF forms), amplifying the business risk
- User Experience Impact: While users could technically enter addresses manually, this option is not immediately obvious in the UI
- Business Impact: No quotes could be processed during the outage across any client or product line, directly affecting revenue
Why This Change is Needed
- Resilience: We have an avoidable single point of failure that affects multiple clients and product lines - a single provider outage takes down quote functionality across the entire business
- Code Exists: The codebase technically supports multiple providers, but only one is implemented and active
- Reusability: Other hut42 projects (Viitata, Forecaster, Katala) require similar geo lookup functionality
- Cost Optimization: Some providers like Google offer free tiers that could serve as fallback options
Proposed Solution
Python Library
A standalone Python library that:
- Abstracts Provider Implementation: Unified interface regardless of underlying provider
- Supports Multiple Providers:
- getaddress.io (primary)
- Google Places API (fallback - potentially free tier)
- Additional providers as needed
- Manual or Automatic Failover: Configurable provider switching (see phased approach below)
- Framework Agnostic: Works with DRF services and Lambda functions
- Built from Existing Code: Refactored from the current geo service codebase
Phased Approach
Phase 1 - Manual Switchover: Implement multi-provider support with manual provider switching via configuration. Service health monitoring handled externally by Uptime Robot, with manual
intervention to switch providers during outages.
Phase 2 - Automatic Failover: Add built-in health checking and automatic failover management to the library, removing the need for manual intervention.
Architecture
Phase 1 - Manual Switchover
┌─────────────────────────────────────────────────────────┐
│ Geo Lookup Library │
├─────────────────────────────────────────────────────────┤
│ GeoLookupClient │
│ ├── Provider Registry │
│ ├── Provider Selector (config-driven) │
│ └── Response Normalizer │
├─────────────────────────────────────────────────────────┤
│ Providers │
│ ├── GetAddressProvider (primary) │
│ ├── GooglePlacesProvider (fallback) │
│ └── BaseProvider (abstract interface) │
└─────────────────────────────────────────────────────────┘
│
▼
┌──────────┐ ┌─────────────────┐
│ Geo Svc │◄───────│ Uptime Robot │
│ │ | (monitoring) │
└──────────┘ └─────────────────┘
│
▼
┌─────────────────┐
│ Manual config │
│ change to swap │
│ provider │
└─────────────────┘
Phase 2 - Automatic Failover
┌─────────────────────────────────────────────────────────┐
│ Geo Lookup Library │
├─────────────────────────────────────────────────────────┤
│ GeoLookupClient │
│ ├── Provider Registry │
│ ├── Health Checker ◄── NEW │
│ ├── Failover Manager ◄── NEW │
│ └── Response Normalizer │
├─────────────────────────────────────────────────────────┤
│ Providers │
│ ├── GetAddressProvider (primary) │
│ ├── GooglePlacesProvider (fallback) │
│ └── BaseProvider (abstract interface) │
└─────────────────────────────────────────────────────────┘
│ │
▼ ▼
┌──────────┐ ┌───────────┐
│ Geo Svc │ │ Geo Svc │
| [Flux] | | [Hutsoft] |
└──────────┘ └───────────┘
Key Features
| Feature | Phase | Description |
|---|
| Provider Abstraction | 1 | Unified API regardless of underlying service |
| Response Normalization | 1 | Consistent response format across all providers |
| Configurable Provider | 1 | Select active provider via configuration |
| External Health Monitoring | 1 | Uptime Robot monitors provider health |
| Manual Switchover | 1 | Change provider via config during outages |
| Metrics & Logging | 1 | Track provider performance and failures |
| Built-in Health Checker | 2 | Periodic health checks on all configured providers |
| Automatic Failover Manager | 2 | Circuit breaker pattern for automatic provider switching |
Affected Applications
Primary Integration
- Universal geo service (immediate integration)
Main Consumers (highest traffic)
- Adrian Flux, Sterling and Bikesure EPAs
- Adrian Flux and Sterling JAF forms
Other Potential Consumers
- Viitata
- Forecaster
- Katala
- Any future projects requiring geo lookup
Impact
API Compatibility
This proposal maintains 100% API compatibility with the existing geo service. No consumer application changes will be required. The library will be integrated behind the existing service
interface, making this change completely transparent to Adrian Flux, Sterling, Bikesure EPAs, JAF forms, and all other consumers.
Services Affected
- Universal geo service (internal code changes for library integration)
- Quote service (indirect - improved reliability)
Technical Considerations
- API compatibility will be maintained for existing geo service consumers
- Response format normalization between different providers
- Rate limiting and quota management per provider
- Caching strategy to reduce API calls and costs
- Configuration management for API keys across environments
Data Considerations
- Different providers may return slightly different address formats
- UK-specific address formatting (getaddress.io strength)
- Postcode validation consistency across providers
Provider Analysis
getaddress.io (Current/Primary)
- Pros: UK-focused, excellent postcode lookup, current integration exists
- Cons: Single point of failure, outage yesterday
- Cost: Paid service
Google Places API (Proposed Fallback)
- Pros: Highly reliable, generous free tier, global coverage
- Cons: Less UK-specific, may require address normalization
- Cost: Free tier available (suitable for fallback volumes)
Other Options to Evaluate
- Postcodes.io (UK specific, open data)
- Ideal Postcodes
- OS Places API
Implementation Plan
Phase 1: Multi-Provider Support with Manual Switchover
1.1 Library Development
1.2 Geo Service Integration
1.3 Monitoring & Rollout
Phase 2: Automatic Health Checking & Failover
2.1 Library Enhancement
2.2 Integration & Rollout
Wider Adoption (Post Phase 1 or 2)
Risks & Mitigation
| Risk | Impact | Phase | Mitigation |
|---|
| Provider response format differences | Medium | 1 & 2 | Robust response normalization and testing |
| Increased complexity | Low | 1 & 2 | Clean abstraction layer, good documentation |
| Google free tier limits exceeded | Low | 1 & 2 | Monitor usage, upgrade plan if needed |
| Manual switchover delay | Medium | 1 | Uptime Robot alerting, documented runbook |
| Failover latency | Low | 2 | Health checks, circuit breaker pattern |
| Address accuracy differences | Medium | 1 & 2 | Thorough testing with UK addresses, consider primary-only for critical paths |
Success Metrics
Phase 1
- Ability to switch providers within minutes of detected outage
- Zero extended quote service outages due to geo provider failures
- Library adoption in at least 2 additional projects within 6 months
- Reduced operational impact from geo lookup alerts
Phase 2
- < 500ms automatic failover time when primary provider fails
- Zero manual intervention required for provider outages
- Reduced operational alerts related to geo lookups
Estimations
Phase 1: 3 days (20 hours)
| Task | Effort |
|---|
| Project setup, current implementation investigation, alternative provider investigation | 4 hours |
| Development build | 8 hours |
| Testing and integration | 8 hours |
Phase 2: 2 days (16 hours)
| Task | Effort |
|---|
| Development build | 8 hours |
| Testing and integration | 8 hours |
Status
Current Status: Draft
History:
- 2025-02-05: Proposal created following getaddress.io outage