SUBSTANTIVELY REVIEWED BY PETER KLAREN · LAST REVIEWED SEPTEMBER 2026 · BASED ON THE WBSO GUIDE 2026
Representative case: this is a representative, anonymised case file based on common WBSO situations — not a literal client file.
Case in eleven phases
1. The company and starting situation
A SaaS company operates a matching platform that links candidates and assignments in real time. As the platform grows, the number of combinations to be assessed increases from 2 million to 20 million per assignment.
2. The technical objective
Maintain matching within a maximum P95 latency of 200 ms and a memory budget of 4 GB per node while increasing data volume tenfold.
3. The software-engineering bottleneck
The existing indexing and query structure compares each new input with too large a portion of the dataset. At 20 million combinations, scoring time exceeds the latency limit and the cache-hit ratio falls sharply.
4. Why known technology was insufficient
Existing libraries, read replicas, caching and regional sharding were tested. The benchmark suite showed that the core problem remained computational: the comparison method itself did not scale. Configuration cannot solve a computational problem.
5. Solution directions investigated
(a) A proprietary partitioning structure dividing the dataset into precomputed buckets.
(b) Incremental scoring that recalculates only deltas.
(c) An approximate preliminary stage followed by exact recalculation for the top candidates.
6. Programming work and experiments
The new structure and scoring method were designed, implemented in a formal programming language (Rust) and tested iteratively. The benchmark suite ran on production-representative datasets; profiler results guided optimisation rounds.
7. Technical result
P95 latency of 180 ms at 20 million combinations and 3.2 GB memory per node, while retaining match quality. The new information-technological operating principle was therefore demonstrated.
8. What qualified as S&O
Designing, implementing in software and iteratively testing the proprietary heuristic and data structure. Benchmarks were used to establish whether the new operating principle actually worked. An algorithm or architecture alone would not have been sufficient.
9. What did not qualify
UX and front-end work, standard API integrations, cloud configuration, database migrations and user documentation.
10. Where the WBSO project ended
The development process ended once benchmarks showed that the new operating principle met the latency and memory requirements. Productisation, hardening and roll-out fell outside the project.
11. Appropriate project records
Git history with technical commit descriptions, issue tracker, benchmark reports, profiler results and design notes (architecture decision records).
How this translates into a WBSO application
| Element | Description |
|---|---|
| Technical objective | real-time matching at 10× data volume, P95 ≤ 200 ms, ≤ 4 GB per node |
| Software-engineering bottleneck | existing index and query structures exceed latency and memory limits |
| Solution direction | proprietary partitioning plus incremental and approximate scoring |
| Technical uncertainty | uncertain whether response time is achievable without substantial loss of quality |
Further reading: WBSO software · project records for software (Git, issues, benchmarks)
Does your project resemble this case?
Share your technical bottleneck or research question. We compare your situation with the WBSO criteria and provide an initial substantive assessment.
Discuss my project
More examples
SOURCES AND SUBSTANTIVE REVIEW
RVO — WBSO Guide 2026
Reviewed by Peter Klaren, WBSO specialist since 2004. Last substantively updated: 21 September 2026. This case is representative, anonymised and not a literal client file.