Nobody Owned the Definition of Active

The Collision of Multiple Realities

In our relational schema, a single column `is_active` resided in the core users table. For years, the database team assumed its meaning was clear and consistent. However, as the engineering, finance, and marketing departments scaled independently, each began applying their own logic to this boolean state. Marketing expected the flag to represent user engagement, looking at logins within the last ninety days. Finance expected it to represent subscription status, tracking paying users. Engineering simply treated it as a marker for active, non-archived user accounts. Without a single, documented owner of the data point, these conflicting expectations remained hidden.

Conflicting Database Updates

The issues became obvious when the marketing team launched a campaign targetting inactive users, only to find the query results shifting arbitrarily. Simultaneously, automated financial runs updated the column based on billing states, while a separate background cron job flipped the flag based on user activity. The field was constantly modified by different systems with opposing logics. Here is a simplified code example showing how different queries expected different realities from the same single field:

-- The marketing service expected login-based status
UPDATE users SET is_active = TRUE WHERE last_login_date >= NOW() - INTERVAL '30 days';

-- The billing microservice expected active paid status
UPDATE users SET is_active = FALSE WHERE subscription_status = 'cancelled';

-- The reporting dashboards queried the column with clashing filters
SELECT count(*) FROM users WHERE is_active = TRUE AND subscription_status = 'active';

Resolving the Lack of Ownership

To clean up the mess and prevent downstream dashboard errors, we deprecated the `is_active` flag. In its place, the architecture team established a clear ownership matrix. Instead of a single column doing everything, we designed separate fields controlled by specific services, separating engagement states from financial statuses.

• We introduced `is_billing_active` controlled strictly by the billing service.
• We implemented a `last_login_at` timestamp to let marketing dynamically compute recency.
• We added database constraints preventing write operations from unauthorized services.