Skip to main content
Version: Beta 🚧

Best Practices

This guide describes best practices for running Tecton in production.

Scale Feature Serving Capacity​

Scale up the Feature Server during capacity planning, especially when expecting the traffic levels to surpass the current capacity provisioned by Tecton. Allow room for spikes in traffic.

Downsize the Feature Server for periods of expected low traffic. For example, if, over the last 10 days, the peak utilization remains below 50% of the allocated capacity, and increased traffic to Tecton is not expected in the near future.

Tecton also provides an API to allow customer-controlled scaling of feature servers (currently in Private Preview).

Use Dashboards to Monitor Your Cluster​

Use Tecton's monitoring dashboards to monitor your clusters.

Overall Feature Serving Dashboard shows:

  • Total Online Serving QPS
  • Latency Distribution
  • Error Distribution

Online Store Dashboard provides:

  • DynamoDB monitoring
  • Redis monitoring

Feature Service Dashboards show:

  • Online Feature QPS
  • Online Success Rate
  • Latency Distribution

Use Variants when Updating Feature Views and Services​

Use a variant naming convention when modifying production Feature Views and Feature Services. Tecton will create new Feature Services andviews, which will show up in the web UI as a variant for better organization.

  • For Feature Views: Tecton by default uses the name of the transformation function as the name of the Feature View. You can specify a variant by adding a colon and tag at the end of the name: name="my_feature_view:v2".

  • For Feature Services: In the name field, add a colon and a tag at the end of the name. For example, if you have a Feature Service with name=my_feature_service, then you might create a modified version of this Feature Service called my_feature_service:v2.

Configure Alerts​

In addition to the monitoring tools above, you can configure Tecton to email you for specific materialization errors via alert_email. Add these configurations to each production Feature View so you are immediately informed of any errors. If you use a paging service such as PagerDuty, consider providing a PagerDuty-connected email address for these notifications.

Integrate with CI/CD​

One benefit of Tecton's code-first configuration and declarative syntax is that you can leverage CI/CD systems to apply feature repository changes.

Store production code in a Git repository and connect the repository to a CI/CD tool, such as Github Actions, to automatically apply feature repository changes.

Was this page helpful?