# Self-Hosted Decision API {% hint style="warning" %} 🚧 Early Adoption Phase This feature is in early adoption, if you want to try it feel free to contact us at " {% endhint %} Although we provide a [cloud-hosted Decision API](/server-side/decision-api/decision-api.md) that is fast and scalable, you can still choose to host the Decision API on your premises instead of using the cloud-hosted one. The data collection part of the AB Tasty FE\&R platform is still hosted on our side, and the Decision API will just batch send the hit tracking calls to our own cloud-hosted data collection on a regular basis. The Decision API that you can install on-premise is almost the same as the cloud-based Decision API. Because the cloud-based Decision API is multi-tenant, and the on-premise version is single-tenant, there are some added connectors in the cloud-based version such as storage interface for visitor assignments. But the decision business logic is completely identical. This guide explains the architectural considerations, benefits, and implementation patterns for deploying FE\&R's Decision API in your own infrastructure. ### Example Implementation #### Architecture Overview The Decision API is a Go based binary or docker image that synchronizes with the use cases you created on the Flagship platform. The decision logic (context targeting & visitor assignments) is done locally, which makes it really fast. A typical self-hosted Decision API implementation follows this architecture: ![self-hosted.png](/files/oQobK1PqR40YE4bKSDMk) ### Reasons to Use Self-Hosted #### SOA (Service-Oriented Architecture) **Microservices Integration** Self-hosting the Decision API aligns perfectly with Service-Oriented Architecture principles: **Benefits:** 1. **Service Independence** * The Decision API runs as an independent service within your architecture * Can be deployed, scaled, and maintained independently of other services * Follows the single responsibility principle 2. **Decoupled Communication** * Services communicate through well-defined APIs * Decision API doesn't directly depend on external SaaS endpoints * Reduces coupling with external dependencies 3. **Service Discovery** * Dynamic endpoint resolution * Health checks and automatic failover #### Cloud-Based API Call Limits **Avoiding External API Throttling** By reducing reliance on external API, you gain more consistent performance, prevent unexpected slowdowns or outages due to throttling, and maintain better control over scalability as your traffic grows. **Issues with Cloud-Based APIs:** * Rate limits * Unpredictable throttling during traffic spikes * Additional costs for exceeding quotas * Potential service degradation during high load **Self-Hosted Advantages:** 1. **Unlimited Internal Calls** * No rate limiting on requests to your own infrastructure * Handle traffic spikes without external throttling * Predictable performance under load 2. **Cost Optimization:** The self-hosted option offers unlimited requests with no per-request charges, resulting in predictable monthly costs. 3. **Scalability Control** * Scale horizontally based on your needs * No external quotas or limits * Add capacity during peak periods 4. **Batch Operations** * Process bulk operations without API limits * Import/export data freely * Run analytics without restrictions #### Network Centralization and Isolation **Security and Network Benefits:** 1. **Network Isolation** It ensures your traffic stay securely contained within your own infrastructure or dedicated environment. By minimizing exposure to external networks. 2. **Limited External Dependencies for Core Operations** * Campaigns are cached locally after initial sync * Continue serving requests even if Flagship CDN is temporarily unreachable * External connectivity is needed solely for configuration polling and analytics collection. #### Observability **Enhanced Visibility:** 1. **Metrics Collection** * Request rates and latencies * Cache hit/miss ratios * Error rates by type * Resource utilization (CPU, memory, network) 2. **Distributed Tracing** To follow the full request flow across services, from the Decision API to custom key/value store and down to the FE\&R CDN. This end-to-end visibility helps you quickly identify where latency, errors, or bottlenecks occur in your infrastructure. 3. **Integration with Observability Stack** Integration with your existing observability stack ensures you can monitor, trace, and debug API usage. #### Latency **Latency Improvements:** 1. **Network Hops Reduction** * Fewer network hops between services * Direct internal communication * No internet routing overhead 2. **Caching Strategy** * In-memory caching for hot paths * Redis for persistent cache (sub-millisecond) * CDN polling only for config updates (default: 1min interval) ### Considerations for Decision API Self-Hosted **Important Limitations and Trade-offs** **1. Configuration Sync Dependency** ⚠️ **Important**: The Decision API requires periodic connectivity to AB Tasty FE\&R's CDN to sync configuration updates. * **Polling Interval**: Default 1 minute (configurable) * **Impact of CDN Unavailability**: * Existing cached configurations continue to work * New campaign launches won't be reflected immediately * Changes to targeting rules may be delayed **Mitigation**: ```yaml environment: # Polling interval for config updates POLLING_INTERVAL: 60s ``` **2. No Built-in Analytics Dashboard** The self-hosted Decision API doesn't include FE\&R's web dashboard. Analytics data is sent to via the activate endpoint. * Campaign activation hits are sent to FE\&R * View reports in dashboard * No local analytics storage **3. Infrastructure Management Responsibility** You are responsible for: * Server provisioning and scaling * Cache management (Redis/Memory/Local/Custom) * Monitoring and alerting * Security updates and patches * Backup and disaster recovery * Network configuration **4. No Automatic Updates** Unlike Cloud-based version, you must manually update to new versions **5. Initial Setup Complexity** * Requires infrastructure knowledge * Cache setup and configuration * Load balancer configuration * Monitoring stack setup **6. Cache Consistency** With multiple Decision API instances: ``` Using same redis instance: Instance 1 → Redis → Assignment stored Instance 2 → Redis → Reads same assignment Using memory: Instance 1 → Memory → Assignment A Instance 2 → Memory → Assignment B (different!) ``` **7. Feature Parity** Some FE\&R platform features may require additional configuration: * Multi-environment management * A/B test allocation changes * Advanced features like 1V1T, XPC and Dynamic Allocation **8. Visitor assignments caching** Thanks to our hashing algorithm, a unique visitor (with a unique ID) will always see the same variation of a use case, if the traffic allocation of the variations stays the same. If you're using a high level Flagship feature such as Experience Continuity, 1 visitor 1 experiment or Dynamic Allocation, or if you manually change the traffic allocation of your variations, the hashing algorithm is not enough. You need some sort of assignment cache to store the visitor assignment to the variation. Flagship cloud-hosted Decision API provides such a caching mechanism for you by default using our own high-velocity key-value store. If you want to use those features when hosting the DecisionAPI on premise, you need to configure your own cache to store visitor assignments. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.abtasty.com/server-side/decision-api/run-on-premise.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.