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
| Scenario | Required Control | Reason |
|---|---|---|
| Development/testing | Sync OFF | Don't want to send test data to production POS |
| Phased release | Partial ON | First Shopify only, add POS later |
| POS failure | POS sync OFF | Avoid errors, continue registrations |
| Maintenance | All sync OFF | Planned outage |
| Load testing | CRM sync OFF | Avoid impact on non-test systems |
Development/testing
Required ControlSync OFF
ReasonDon't want to send test data to production POS
Phased release
Required ControlPartial ON
ReasonFirst Shopify only, add POS later
POS failure
Required ControlPOS sync OFF
ReasonAvoid errors, continue registrations
Maintenance
Required ControlAll sync OFF
ReasonPlanned outage
Load testing
Required ControlCRM sync OFF
ReasonAvoid impact on non-test systems
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 Variable | true | false |
|---|---|---|
| ENABLE_POS_SYNC | Auto sync to POS on registration | Register to Shopify only (POS manual) |
| ENABLE_CRM_SYNC | Auto sync to HubSpot | No CRM integration |
| ENABLE_UPDATE_SYNC | Sync on customer info update | Sync only on new registration |
ENABLE_POS_SYNC
trueAuto sync to POS on registration
falseRegister to Shopify only (POS manual)
ENABLE_CRM_SYNC
trueAuto sync to HubSpot
falseNo CRM integration
ENABLE_UPDATE_SYNC
trueSync on customer info update
falseSync only on new registration
Environment-Specific Settings Example
| Environment | POS Sync | CRM Sync | Update Sync | Notes |
|---|---|---|---|---|
| Production | ON | ON | ON | Full functionality |
| Staging | ON | OFF | ON | Test POS integration only |
| Development | OFF | OFF | OFF | For local development |
| E2E Test | OFF | OFF | OFF | For automated tests |
Production
POS SyncON
CRM SyncON
Update SyncON
NotesFull functionality
Staging
POS SyncON
CRM SyncOFF
Update SyncON
NotesTest POS integration only
Development
POS SyncOFF
CRM SyncOFF
Update SyncOFF
NotesFor local development
E2E Test
POS SyncOFF
CRM SyncOFF
Update SyncOFF
NotesFor automated tests
Integration into Processing Flow
Conditional Branching Concept
Sync Processing Conditional Branching
Receive customer registration request
Receive data submitted from form
Shopify registration (always executed)
Highest priority registration as customer master
Check ENABLE_POS_SYNC
ON -> Execute POS sync / OFF -> Skip (log)
Check ENABLE_CRM_SYNC
ON -> Execute CRM sync / OFF -> Skip (log)
Registration complete
Return result to customer
Log Recording on Skip
Even when sync is skipped, leave logs for later tracking.
| Field | Value | Description |
|---|---|---|
| timestamp | 2024-01-15T10:30:00Z | Processing time |
| event | customer_registration | Event type |
| shopify_customer_id | 12345 | Customer ID |
| sync_status.shopify | success | Shopify registration result |
| sync_status.pos | skipped (disabled) | POS sync result (record skip reason) |
| sync_status.crm | success | CRM sync result |
timestamp
Value2024-01-15T10:30:00Z
DescriptionProcessing time
event
Valuecustomer_registration
DescriptionEvent type
shopify_customer_id
Value12345
DescriptionCustomer ID
sync_status.shopify
Valuesuccess
DescriptionShopify registration result
sync_status.pos
Valueskipped (disabled)
DescriptionPOS sync result (record skip reason)
sync_status.crm
Valuesuccess
DescriptionCRM sync result
Can later track "why not synced to POS".
Operational Scenarios
Scenario 1: Phased Release
Phase 1: Shopify only
POS sync OFF, CRM sync OFF for production release. First verify basic functionality
Phase 2: Add POS
Change POS sync to ON. Batch sync Shopify-registered customers to POS
Phase 3: Add CRM
Change CRM sync to ON. Start marketing integration
Scenario 2: Isolation During Failure
Response When POS Failure Occurs
Normal operation
POS sync: ON, CRM sync: ON, All working normally
During failure response
POS sync: Change to OFF (immediate switch), CRM sync: ON (no impact), Customer registration continues
After recovery
POS sync: Return to ON, Batch sync registrations during failure, Return to normal operation
Scenario 3: Control in Test Environment
| Environment | POS Sync | POS Connection | Characteristics |
|---|---|---|---|
| Developer local | OFF | - | No impact on production systems |
| Staging | ON | staging-pos.example.com | Can verify with staging POS |
| Production | ON | pos.example.com | Integrated with production POS |
Developer local
POS SyncOFF
POS Connection-
CharacteristicsNo impact on production systems
Staging
POS SyncON
POS Connectionstaging-pos.example.com
CharacteristicsCan verify with staging POS
Production
POS SyncON
POS Connectionpos.example.com
CharacteristicsIntegrated with production POS
Design Considerations
Timing of Flag Check
Default Value Design
| Flag | Default When Unset | Reason |
|---|---|---|
| ENABLE_POS_SYNC | false | Prevent unintended sync |
| ENABLE_CRM_SYNC | false | Prevent unintended sync |
| ENABLE_UPDATE_SYNC | false | Safely operate new registrations only |
ENABLE_POS_SYNC
Default When Unsetfalse
ReasonPrevent unintended sync
ENABLE_CRM_SYNC
Default When Unsetfalse
ReasonPrevent unintended sync
ENABLE_UPDATE_SYNC
Default When Unsetfalse
ReasonSafely operate new registrations only
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