Skip to main content

Rate Limiting Functionality for Publix Pro Chat

Overview​

Rate limiting in Publix Pro Chat is used to control the number of requests a user can make within a specific time window, as well as to limit the number of messages an individual user can make within a specific time window. This helps maintain system stability, prevent abuse, and ensure consistent user experience. This works only when the above flag is set; if not, there is no restriction on the number of messages sent per day.

Enforcement Mechanism​

Rate Limiting Logic is enforced at the Web API layer. The Web API checks the user's current quota before processing a request. If the quota is exhausted, the API blocks further requests and returns a friendly error message:

"Your chat request threshold exceeded for the day"

Sample Response​

{
  "error": "Your chat request threshold exceeded for the day",
  "statusCode": 429,
  "timestamp": "2025-11-05T00:00:00Z"
}

Configuration​

Default Quota​

  • The default request quota is specified in the configuration settings (Default RequestQuota is 9999)
  • New users are assigned the current default quota when they make their first request

Custom Quotas​

  • Users with HasDifferentRequestQuota set to true retain their custom quota even after a job refresh
  • This flag is used solely for audit purposes and ensures that custom quotas are not overwritten during quota resets

Configuration Value​

When users are rate limited, the response message displayed is governed by the configuration value UserMessages:RateLimitExceeded.

Databricks Job​

Job Names​

  • Staging: S0itmolm-chat-rate-limit-refresh-stg
  • Test: S0itmolm-chat-rate-limit-refresh-tst

Job Behavior​

  • Databricks Refresh Job resets CurrentRequestsLeft column to match the RequestQuota value
  • Clones existing quotas

Job Scheduling​

  • Rate limiting values are reset daily by a scheduled job
  • Runs on Eastern Standard Time (EST)
  • Users in Central Standard Time (CST) may observe the reset occurring slightly before midnight in their local time

Observations from Rate Limit Refresh Job – October 15, 2025​

The following observations were made after the successful execution of the Rate Limit refresh job on October 15, 2025, at 9:07 PM:

RateLimit Table Behavior​

  • The [dbo].[RateLimit] table accurately resets the CurrentRequestsLeft column to match the RequestQuota value for all existing records

RateLimitLog Table Behavior​

  • The [dbo].[RateLimitLog] table is updated by appending all rows from the [dbo].[RateLimit] table
  • The RequestsMade column is accurately populated to reflect the number of requests made prior to the reset

Configuration Value Behavior​

The refresh job does not reference the configuration value for quotas for the existing users in the RateLimit table. Instead, it:

  • Clones the existing values from the RateLimit table
  • Resets the CurrentRequestsLeft to the corresponding RequestQuota

The Web API utilizes the configuration value only when inserting quota values for new users.

Example Scenario​

  • If the configuration value is set to 9999 today and a user accesses the app for the first time, their quota will be set to 9999
  • If the configuration value is changed to 100 tomorrow, a new user accessing the app will receive a quota of 100
  • These quotas are persisted in the database and are not retroactively updated for existing users

Manual Update Requirement​

If there is a need to update the quota for all existing users or a specific user (e.g., from 9999 to 100), this must be done manually. A SQL support task would be required in the production environment to update all relevant records in the RateLimit table.

Sample SQL Query​

UPDATE [dbo].[RateLimit] 
SET RequestQuota = 100
WHERE UserId = 'P1324590';

Troubleshooting Tips​

SymptomPossible CauseResolution
User blocked unexpectedlyQuota = 0Check RateLimit table
Quota not updated after config changeExisting users retain old quotaManual SQL update required

Rate Limiting Process Flow​

Database Schema Reference​

RateLimit Table​

  • UserId - User identifier
  • RequestQuota - Maximum requests allowed per day
  • CurrentRequestsLeft - Remaining requests for current day
  • HasDifferentRequestQuota - Flag for custom quota users

RateLimitLog Table​

  • Historical log of rate limit resets
  • RequestsMade - Number of requests made before reset
  • Populated during daily refresh job