A sudden change in fee activity can indicate a pricing defect, but it can also be the expected result of a promotion ending, a marketplace fee structure changing, or customer activity shifting. Distinguishing among these scenarios requires more than aggregate fee totals: investigators need timely historical data and the item, seller, marketplace, and campaign context behind each fee decision.
Before Minerva, eBay’s Monetization Team lacked a dedicated observability platform that brought this information together. Transactional data in datawarehouse (HDFS) arrived too late for timely launch monitoring, and investigations often required engineers and business teams to query multiple data sources and manually assemble comparisons. In many cases, unexpected fee behavior became visible only through customer complaints or post-transaction analysis by business units. This made it difficult to identify localized issues quickly or determine whether a change required action.
Minerva was built to fill this observability gap without adding latency or availability risk to the core services that calculate and charge fees. It captures a small monitoring record locally, enriches it asynchronously, stores the resulting history in ClickHouse, and evaluates it through reusable dashboards and monitoring use cases. This approach gives operators a shared view of fee behavior and its business context while keeping remote monitoring dependencies off the fee-processing path.
The monetization observability gap
In Q2 2026, eBay reported $22.4 billion in gross merchandise volume, 136 million active buyers, and 2.6 billion active listings worldwide. Pricing, promotions, and subscriptions depend on a complex mix of approximately 200 item, seller, marketplace, and campaign attributes. This complexity makes monetization systems challenging to maintain — and means that diagnosing a localized issue requires retaining both large volumes of events and the contextual attributes behind each decision.
At this scale, aggregate correctness is not enough. A global total can look normal while activity for one site, fee type, promotion, or time period behaves unexpectedly. Conversely, an abrupt change can be entirely expected because a promotion expired or a product rollout changed traffic. Monitoring therefore has to preserve enough dimensions to answer both questions: What changed, and why did it change?
The system that preceded Minerva had three practical limitations.
First, Datawarehouse data arrived too late for launch monitoring. A daily view could confirm an issue after the fact, but it could not support an operator watching a fee rollout hour by hour. Furthermore, usually datawarehouse data lies in a different security zone, making it difficult to access the data.
Second, investigation required manual data work. Engineers queried multiple sources and assembled comparisons for each event. This made the response dependent on specialist availability and made it difficult to provide reusable visualizations to product and business users.
Third, issue detection was not realtime. Problems were typically discovered through customer complaints or post-transaction analysis performed by business units. As a result, incorrect fee behavior could remain undetected for hours or days — after transactions had already been completed and seller-facing investigation or remediation might be required.
Minerva was built to fill this observability gap without introducing a new risk: monitoring could not slow down or destabilize the service responsible for calculating and charging fees.
Figure 1 shows the design of Minerva. The article focuses on its core pattern: the fee-processing service makes the online decision, while an asynchronous observability pipeline enriches, stores, and interprets the resulting monitoring record.
Figure 1. Minerva's end-to-end architecture. The fee-processing service records the fee decision and enqueues only the identifiers needed for monitoring. The asynchronous pipeline publishes and enriches the event, writes batches of enriched records to ClickHouse, and exposes the resulting history to dashboards and alert evaluation.
Keeping observability off the real-time fee-processing path
Publishing directly from a fee-processing request to a remote event stream would couple monitoring availability to fee-processing availability. A slow network call, unavailable broker, or downstream backpressure could increase request latency or consume resources needed by production traffic.
Minerva reduces this coupling by having the fee-processing service place a small record — containing identifiers for the item and fee-calculation event — on a local queue. A background producer drains the queue and publishes each record to the event stream. Under normal conditions, the request does not wait for network publication, enrichment, analytical storage, or alert evaluation.
The local queue absorbs short-lived downstream delays, but it does not eliminate backpressure. If the producer cannot drain the queue for an extended period, the backlog can eventually consume resources and affect the fee-processing service. To contain this risk, the queue is bounded by capacity and record age. Records that cannot be processed within a configured interval can be flushed or overwritten, following a ring-buffer-style policy, rather than allowing the backlog to grow indefinitely.
This behavior deliberately prioritizes fee-processing availability over lossless monitoring delivery. Minerva’s event stream is used for granular, time-window-based monitoring and is not the transactional source of truth for fee decisions. A prolonged downstream interruption may therefore create a gap in monitoring data, but it cannot change or invalidate the original fee calculation.
Because the initial record contains only identifiers, a background consumer subsequently queries the transaction read database and retrieves the relevant fee, listing, account, and promotion attributes from transactional sources. The enriched records support dashboards and monitoring queries without requiring repeated joins across multiple operational stores. This asynchronous enrichment makes monitoring eventually consistent: the data becomes available after the fee decision, while the fee-processing request remains isolated from the analytical work.
Making fee history queryable
Minerva's common queries - Fee trends by site, category, user; Promotion usage by site, category, user etc. aggregate a small set of fields — such as fee amount, site, fee type, promotion, and time — across millions of records with each record having almost 250 columns. The transactional databases serving live fee requests are not designed for repeated historical scans of this kind, so the team selected ClickHouse as the analytical store.
ClickHouse stores data by column, allowing a query to read the fields it needs rather than every attribute in every row. Its MergeTree family of table engines also provides ordering and partitioning controls that can be aligned with common monitoring access patterns.
An early proof of concept tested approximately 1.1 billion listing-session rows on a machine with six virtual CPUs and 44 GB of memory. Sample lookups and aggregations completed in less than one second, with reported examples ranging from approximately 0.11 to 0.72 seconds. These measurements established feasibility for the initial design, but they were not a production benchmark: the notes do not record repeated runs, cache state, concurrency, compression, or a comparison baseline.
The first data model organized records around listing-session and account-event identifiers and collected fee, currency, transaction, listing, and promotion attributes during ingestion. This reduced the need to reconstruct each business event from operational databases during every investigation. For analyses that grouped activity by seller and item, the design also considered placing the related records on the same shard to reduce cross-node work.
Modeling monetization data introduced domain-specific tradeoffs. A listing can have a base fee and multiple promotional adjustments. Flattening those values simplifies some scans but duplicates context; joining normalized records avoids duplication but adds work at query time. Minerva also consumes upstream fee and promotion decisions rather than reimplementing those rules. Its role is to observe monetization outcomes, not become a second fee-calculation engine.
Turning data into signals
Storing the data made investigation possible. The next step was to evaluate it repeatedly and route useful signals to the right responders. The original monitoring service divided that work into three modules: query execution, use-case processing, and notification delivery.
Figure 2. Turning stored data into actionable signals. Minerva processes ClickHouse history through three stages: query execution, use-case processing, and notification delivery.
The query-execution module identifies eligible queries and checks their cadence. Because multiple monitoring instances can run simultaneously, they coordinate so that only one instance evaluates each scheduled query. When a monitoring use case depends on several queries, processing waits until the required result set is available.
The use-case processor applies the logic required for each signal. One processor might calculate a fee-amount deviation; another might compare transaction count by site and hour; another could combine fee and promotion data to interpret a spike. The processor evaluates the metric, assigns severity, and creates a notification model with the supporting context.
The notification module selects the configured destination and constructs a channel-specific payload for PagerDuty, email, or Slack. Settings can be defined broadly and then overridden for a particular monitoring rule or data segment — for example, routing a high-severity country-level fee deviation to PagerDuty while sending a lower-severity trend by email. New use cases can therefore be added without changing the fee-processing service or ingestion pipeline.
Conclusion
By keeping observability off the critical fee path and combining high-volume history with configurable, context-aware monitoring, Minerva gives the Monetization Team a safer, more timely way to observe pricing changes. The same design provides a foundation for new monitoring use cases: as fee products, promotions, and operating patterns evolve, teams can add queries, processing logic, and notifications without changing the fee-processing service itself. This separation between making a fee decision and explaining the resulting behavior is Minerva’s central contribution, enabling the platform to evolve alongside eBay’s monetization systems.