┌─────────────────────────────────────────────────────────────────┐
│ Phase 1: Requirements Gathering (10-15 minutes)                │
├─────────────────────────────────────────────────────────────────┤
│ • Clarify business model (B2B, B2C, marketplace)               │
│ • Define scale (users, products, transactions)                 │
│ • Identify key features (search, cart, payments, inventory)    │
│ • Discuss compliance requirements (PCI DSS, GDPR)              │
└─────────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────────┐
│ Phase 2: High-Level Architecture (15-20 minutes)               │
├─────────────────────────────────────────────────────────────────┤
│ • Draw microservices architecture                              │
│ • Define service boundaries and responsibilities               │
│ • Show data flow for key operations                            │
│ • Discuss API design and communication patterns                │
└─────────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────────┐
│ Phase 3: Deep Dive (15-20 minutes)                             │
├─────────────────────────────────────────────────────────────────┤
│ • Database design and data modeling                            │
│ • Scaling strategies and performance optimization              │
│ • Consistency and transaction handling                         │
│ • Security and fraud prevention                                │
└─────────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────────┐
│ Phase 4: Follow-up Questions (5-10 minutes)                    │
├─────────────────────────────────────────────────────────────────┤
│ • Handle edge cases and failure scenarios                      │
│ • Discuss monitoring and observability                         │
│ • Address specific technical challenges                        │
└─────────────────────────────────────────────────────────────────┘

# Business Model Clarification
CLARIFYING_QUESTIONS = [
    "Is this B2B, B2C, or a marketplace platform?",
    "What's the expected scale - users, products, transactions per second?",
    "What payment methods need to be supported?",
    "Are there inventory management requirements?",
    "Do we need to support international markets and currencies?",
    "What compliance requirements exist (PCI DSS, GDPR, etc.)?",
    "Are there specific performance requirements (response time, availability)?",
    "What's the budget for infrastructure and third-party services?"
]

# Technical Scope Questions
TECHNICAL_QUESTIONS = [
    "Should we focus on the core e-commerce platform or include analytics?",
    "Do we need real-time inventory updates across multiple warehouses?",
    "How important is search functionality - basic or advanced with ML?",
    "Are there specific security requirements beyond standard practices?",
    "Do we need to handle flash sales or high-traffic events?",
    "Should we design for mobile-first or web-first experience?"
]

# ACID vs BASE tradeoffs
def discuss_transaction_consistency():
    """
    Strong Consistency (ACID):
    - Use for: Payment processing, inventory allocation, financial records
    - Implementation: Database transactions, two-phase commit
    - Tradeoff: Lower throughput, potential blocking
    
    Eventual Consistency (BASE):
    - Use for: Product catalog, user profiles, analytics
    - Implementation: Event sourcing, CQRS, saga pattern
    - Tradeoff: Higher complexity, compensation logic needed
    """
    
    # Example: Order processing with mixed consistency
    order_processing_flow = {
        'strong_consistency': [
            'Payment authorization',
            'Inventory reservation',
            'Order creation'
        ],
        'eventual_consistency': [
            'Search index updates',
            'Recommendation engine updates',
            'Analytics data processing',
            'Email notifications'
        ]
    }
    
    return order_processing_flow

# Demonstrate understanding of when to use each approach

# Multi-warehouse inventory challenges
class InventoryScalingDiscussion:
    def discuss_challenges(self):
        return {
            'real_time_updates': {
                'challenge': 'Keeping inventory accurate across warehouses',
                'solution': 'Event-driven updates with eventual consistency',
                'fallback': 'Periodic reconciliation jobs'
            },
            'allocation_strategy': {
                'challenge': 'Optimal warehouse selection for orders',
                'solution': 'Distance-based allocation with cost optimization',
                'considerations': ['Shipping cost', 'Delivery time', 'Stock levels']
            },
            'reservation_handling': {
                'challenge': 'Preventing overselling during checkout',
                'solution': 'Optimistic locking with compensation',
                'timeout': 'Release reservations after 15 minutes'
            }
        }
    
    def discuss_edge_cases(self):
        return [
            'What happens when payment fails after inventory reservation?',
            'How do you handle partial inventory availability?',
            'How do you prevent race conditions during flash sales?',
            'What if a warehouse goes offline during order processing?'
        ]

# PCI DSS compliance discussion
def discuss_payment_security():
    security_layers = {
        'data_protection': {
            'tokenization': 'Replace card numbers with tokens',
            'encryption': 'AES-256 for data at rest, TLS 1.3 for transit',
            'key_management': 'Hardware Security Modules (HSM)'
        },
        'fraud_prevention': {
            'real_time_scoring': 'ML-based fraud detection',
            'rule_engine': 'Configurable business rules',
            'device_fingerprinting': 'Track device characteristics',
            'velocity_checks': 'Monitor transaction patterns'
        },
        'compliance': {
            'pci_dss': 'Level 1 merchant compliance',
            'audit_trails': 'Immutable transaction logs',
            'access_controls': 'Role-based permissions',
            'network_security': 'Segmented payment processing'
        }
    }
    
    return security_layers

# Common interview question: "How do you store credit card information?"
# Answer: "We don't store it - we use tokenization and work with PCI-compliant payment processors"

# Search architecture discussion
def discuss_search_scaling():
    search_architecture = {
        'data_pipeline': {
            'source': 'Product database (PostgreSQL/MongoDB)',
            'processing': 'ETL pipeline for search index updates',
            'destination': 'Elasticsearch cluster',
            'frequency': 'Real-time for inventory, batch for catalog'
        },
        'search_features': {
            'full_text_search': 'Multi-field search with boosting',
            'faceted_search': 'Category, brand, price range filters',
            'autocomplete': 'Trie-based suggestions with caching',
            'personalization': 'User behavior-based ranking'
        },
        'performance_optimization': {
            'caching': 'Redis for popular searches',
            'sharding': 'Distribute index across nodes',
            'replication': 'Multiple replicas for availability',
            'query_optimization': 'Index warming and query profiling'
        }
    }
    
    return search_architecture

# ❌ Wrong approach - jumping to complex solutions
def wrong_approach():
    return {
        'mistake': 'Starting with microservices for a small e-commerce site',
        'consequence': 'Unnecessary complexity, longer development time',
        'better_approach': 'Start with modular monolith, extract services as needed'
    }

# ✅ Right approach - progressive complexity
def right_approach():
    return {
        'phase_1': 'Monolithic application with clear module boundaries',
        'phase_2': 'Extract high-traffic services (search, recommendations)',
        'phase_3': 'Full microservices as team and scale grow',
        'rationale': 'Matches organizational and technical maturity'
    }

# ❌ Technical-only thinking
def technical_only_mistake():
    return "Designing for Amazon-scale when building for 1000 users"

# ✅ Business-aware design
def business_aware_approach():
    return {
        'startup_ecommerce': {
            'users': '< 10K',
            'architecture': 'Monolith with managed services',
            'database': 'Single PostgreSQL instance',
            'focus': 'Speed to market, cost efficiency'
        },
        'growing_business': {
            'users': '10K - 1M',
            'architecture': 'Modular monolith with some services',
            'database': 'Master-replica setup',
            'focus': 'Performance optimization, team scaling'
        },
        'enterprise_scale': {
            'users': '> 1M',
            'architecture': 'Full microservices',
            'database': 'Sharded, multi-region',
            'focus': 'Reliability, global scale'
        }
    }

# Common mistake: Not explaining consistency tradeoffs
def consistency_discussion_framework():
    return {
        'identify_data_types': {
            'financial': 'Strong consistency required',
            'catalog': 'Eventual consistency acceptable',
            'user_activity': 'Eventual consistency preferred'
        },
        'explain_tradeoffs': {
            'strong_consistency': 'Accuracy vs Performance',
            'eventual_consistency': 'Performance vs Temporary inconsistency'
        },
        'provide_examples': {
            'payment_processing': 'ACID transactions prevent double charging',
            'search_updates': 'Slight delay in search results is acceptable'
        }
    }

# Must discuss failure scenarios
def failure_scenarios_to_cover():
    return {
        'payment_failures': {
            'scenario': 'Credit card declined during checkout',
            'handling': 'Graceful error message, alternative payment options',
            'cleanup': 'Release inventory reservation'
        },
        'inventory_issues': {
            'scenario': 'Product goes out of stock during checkout',
            'handling': 'Real-time inventory check, suggest alternatives',
            'prevention': 'Inventory reservation system'
        },
        'service_outages': {
            'scenario': 'Search service is down',
            'handling': 'Fallback to database search, cached results',
            'monitoring': 'Circuit breakers, health checks'
        },
        'data_corruption': {
            'scenario': 'Database corruption affects orders',
            'handling': 'Point-in-time recovery, data validation',
            'prevention': 'Regular backups, checksums'
        }
    }

# Show advanced architectural knowledge
def event_sourcing_discussion():
    return {
        'use_case': 'Financial transaction audit trails',
        'benefits': [
            'Complete audit history',
            'Ability to replay events',
            'Temporal queries',
            'Debugging capabilities'
        ],
        'implementation': {
            'event_store': 'Immutable event log',
            'projections': 'Materialized views for queries',
            'snapshots': 'Performance optimization for long histories'
        },
        'example_events': [
            'OrderPlaced', 'PaymentProcessed', 'InventoryReserved',
            'OrderShipped', 'OrderDelivered', 'OrderCancelled'
        ]
    }

def cqrs_discussion():
    return {
        'motivation': 'Different read and write patterns for e-commerce',
        'write_side': {
            'focus': 'Consistency, validation, business rules',
            'database': 'Normalized relational database',
            'operations': 'Create order, update inventory, process payment'
        },
        'read_side': {
            'focus': 'Performance, complex queries, reporting',
            'database': 'Denormalized, optimized for reads',
            'operations': 'Product search, order history, analytics'
        },
        'synchronization': 'Event-driven updates from write to read side'
    }

def ml_integration_discussion():
    return {
        'recommendation_engine': {
            'algorithms': 'Collaborative filtering, content-based',
            'data_pipeline': 'Real-time user behavior tracking',
            'serving': 'Pre-computed recommendations with real-time updates'
        },
        'fraud_detection': {
            'features': 'Transaction patterns, device fingerprints, geolocation',
            'model': 'Ensemble of decision trees and neural networks',
            'deployment': 'Real-time scoring with sub-100ms latency'
        },
        'dynamic_pricing': {
            'factors': 'Demand, competition, inventory levels, seasonality',
            'optimization': 'Revenue maximization with demand elasticity',
            'constraints': 'Brand guidelines, minimum margins'
        }
    }

def flash_sale_strategy():
    return {
        'preparation': {
            'inventory_pre_allocation': 'Reserve inventory for flash sale',
            'capacity_planning': 'Scale infrastructure before event',
            'queue_system': 'Implement waiting room for traffic control'
        },
        'during_sale': {
            'rate_limiting': 'Limit requests per user to prevent bots',
            'inventory_checks': 'Real-time inventory validation',
            'queue_processing': 'FIFO queue for fairness'
        },
        'technical_implementation': {
            'caching': 'Cache product details and pricing',
            'database_optimization': 'Read replicas for product queries',
            'async_processing': 'Queue order processing to handle spikes'
        }
    }

# Key point: Emphasize fairness, performance, and preventing overselling

def microservices_consistency_strategy():
    return {
        'saga_pattern': {
            'use_case': 'Distributed transactions across services',
            'implementation': 'Choreography-based saga for order processing',
            'compensation': 'Rollback actions for failed steps'
        },
        'event_sourcing': {
            'use_case': 'Audit trails and state reconstruction',
            'benefits': 'Complete history, replay capability',
            'challenges': 'Event schema evolution, storage growth'
        },
        'eventual_consistency': {
            'acceptable_scenarios': 'Search updates, analytics',
            'monitoring': 'Track consistency lag and alert on delays',
            'reconciliation': 'Periodic jobs to fix inconsistencies'
        }
    }

def flexible_product_schema():
    return {
        'hybrid_approach': {
            'core_attributes': 'Structured columns (title, price, category)',
            'flexible_attributes': 'JSON/JSONB column for varying properties',
            'search_optimization': 'Separate search index for attribute queries'
        },
        'alternatives': {
            'eav_model': 'Entity-Attribute-Value for maximum flexibility',
            'document_store': 'MongoDB for schema-less product data',
            'graph_database': 'Neo4j for complex product relationships'
        },
        'recommendation': 'PostgreSQL with JSONB for balance of structure and flexibility'
    }