Case 003 · Re-architecture and migration leadership
Visualping: From Monolith to Microservices
Visualping's legacy monolith monitored billions of web pages for two million customers. The engagement defined and delivered a route to independent services without stopping the product.
Engagement facts
| Fact | Detail |
|---|---|
| Client | Visualping, web page change monitoring, two million customers |
| Counterpart | Several in-house development teams, carrying the bulk of the implementation |
| Period | January 2022 to June 2023, 18 months |
| Format | Part-time and flexible, engaged at every decisive step |
| Scope | Audit, target architecture, migration plan, and critical-path implementation |
| Fee | CAD $118,200, invoiced at CAD $200 per hour |
Design lenses applied
Scaling headroom at crawl volume, infrastructure cost per monitored page, team autonomy and delivery velocity, migration risk and service continuity, and end-user latency shaped the target architecture and migration sequence.
Measured outcome
The AWS bill was divided by four, saving roughly $850,000 per year. Development speed increased fivefold once each service had a single owning team.
The programme was delivered on schedule against the original 18-month plan, with additional scope included along the way.
How the programme ran
- Audit the running system. The monolith was read end to end and measured under real crawl load. Bottlenecks, scaling cost, and the couplings slowing every team were named and quantified before a target was drawn.
- Design the target and the route to it. Blobb designed a decoupled set of microservices around clear team ownership, then sequenced what would move first, what could run in parallel, and what the monolith would retain until last.
- Build the critical path and hand over the rest. Visualping’s teams completed most of the implementation. Blobb remained embedded part-time, built where risk concentrated, and reviewed and corrected course at each milestone.
Workstream register
| ID | Workstream and measured result | Classification |
|---|---|---|
| W-01 | Distributed job scheduler. The highest-volume path was rebuilt as a distributed scheduler, removing its scaling ceiling. | Critical path |
| W-02 | Web crawling engine. The crawler became an independent service designed around the real cost of fetching and comparing a page, reducing crawling time by 40% to 90%, depending on the page. | Critical path |
| W-03 | Independent frontend. The user interface was extracted and rebuilt as a standalone React application with its own release cadence, reducing latency on UI requests by 75%. | Structural |
| W-04 | Service ownership. Boundaries were drawn so each microservice had one owning team, increasing development speed fivefold. | Structural |
| W-05 | Infrastructure cost. Independent scaling let capacity follow demand per workload, helping divide AWS spend by four and save roughly $850,000 per year. | Structural |
What was left with the client
An audit of the legacy platform, a target architecture mapped to owning teams, a sequenced 18-month migration plan, a distributed job scheduler and crawling engine built alongside the teams, an independently released React frontend, and an engineering organization able to ship faster.
Figures as measured at engagement close. Further detail is available under NDA.
Explore Blobb’s architecture work or book a call to discuss a similar re-architecture.