PortfolioAbout This Article
There are cases where you want different sync behavior between production and test environments, or temporarily stop sync. Therefore, we designed the system to control sync ON/OFF via environment variables.
Why Sync Control is Needed
Scenarios Requiring Control
Problems Without Control
- Test data gets registered in production POS
- All registrations fail during POS failure
- Cannot do partial feature releases
Design for Environment Variable Control
Basic Concept
Environment-Specific Settings Example
Integration into Processing Flow
Conditional Branching Concept
Receive data submitted from form
Highest priority registration as customer master
ON -> Execute POS sync / OFF -> Skip (log)
ON -> Execute CRM sync / OFF -> Skip (log)
Return result to customer
Log Recording on Skip
Even when sync is skipped, leave logs for later tracking.
Can later track "why not synced to POS".
Operational Scenarios
Scenario 1: Phased Release
POS sync OFF, CRM sync OFF for production release. First verify basic functionality
Change POS sync to ON. Batch sync Shopify-registered customers to POS
Change CRM sync to ON. Start marketing integration
Scenario 2: Isolation During Failure
POS sync: ON, CRM sync: ON, All working normally
POS sync: Change to OFF (immediate switch), CRM sync: ON (no impact), Customer registration continues
POS sync: Return to ON, Batch sync registrations during failure, Return to normal operation
Scenario 3: Control in Test Environment
Design Considerations
Timing of Flag Check
Default Value Design
Benefits of This Design
For Development Team
- Don't pollute production systems during testing
- Enables phased releases
- Can minimize failure impact
For Operations Team
- Quick response possible during failures
- Easy control during maintenance
- Settings changeable without deployment
For Business
- Minimized service downtime
- Risk-reduced feature additions
- Flexible operational structure achieved