Comparor: turning heterogeneous sources into comparable information
Comparor combines acquisition, normalization, search and data updates. It is software whose value depends as much on data quality as on the application presenting it.
The problem behind the product
Commercial sources change structure, availability and frequency. To provide useful comparison, the system needs origin, freshness and quality for each value while sustaining workflows that can partially fail.
- Ingest catalogues with different formats and quality.
- Detect source changes without breaking the entire flow.
- Normalize products and attributes while preserving traceability.
- Refresh information at controlled operating cost.
- Separate temporary unavailability from permanent failure.
Capabilities built into the system
The description is limited to observable capabilities and does not claim undocumented metrics.
Connectors, crawling and imports with source control.
Transform fields, categories, units and attributes.
Validation, states and incomplete-record handling.
Resumable batch jobs with retries and limits.
Structures optimized for search and comparison.
Source, error, coverage and freshness monitoring.
Turn operational complexity into maintainable capabilities
A case is not explained only by the technologies used. Chosen boundaries, operating conditions and the way outcomes are verified matter.
Design separates what must remain coherent from what can evolve independently. Business rules, data, asynchronous processes and integrations have different rhythms and failure modes; making those differences visible enables one capability to change without spreading exceptions across the platform.
Operations are part of the solution. Every important flow needs signals to recognise its state, error handling, ownership and a recovery path. Case evidence lies in capabilities the product can use and the team can maintain, not in an idealised architecture.
- ContextUsers, operations, constraints and actual risk.
- BoundariesResponsibilities and contracts reducing coupling.
- OperationsObservation, errors, retries and recovery.
- EvidenceObservable capabilities and reusable knowledge.
How responsibilities are separated
An explanatory model, not a reproduction of confidential infrastructure.
- Pipeline split into acquisition, validation, normalization and publication.
- Source and state retained to explain each value.
- Batch jobs resumable without repeating all work.
- Read model optimized for the search experience.
What this experience demonstrates
- Architecture separating data quality from presentation.
- Ability to add or fix sources without redesigning the product.
- Experience applicable to catalogues, imports, crawling and bulk processing.
Reusable principles
A pipeline must explain why a record was not published.
Per-source observability is more useful than a global error rate.
Normalization requires business decisions, not only technical transformations.
Content connected to this decision
Continue with diagnosis, execution or related experience.
Let’s discuss what your PHP application needs
Tell us about the context, the main blocker and the outcome you need. We will reply with the questions required for an initial assessment.
- No commercial commitment
- Direct contact with the team
- Your details are not sold to third parties