Knowbly Learning Systems

Knowbly is an authoring platform for e-learning content: instructors build books made of deeply nested documents, and learners consume them. I worked on the backend from Tacna for a team based in California, which meant most decisions had to survive being explained asynchronously, in writing, to people who were asleep when I wrote them.

The bottleneck was the gateway that did not exist

The services had grown organically. Each one handled its own auth, its own rate limiting, its own logging, in its own way. Every new integration re-litigated the same three problems, and nobody could answer "how is this endpoint actually performing" without going service by service.

I introduced a Tyk API Gateway as the single entry point. Auth, rate limiting, and monitoring moved out of the individual services and into one layer. That plus the microservices redesign and the automation around it cut API response times by 30%.

The part that mattered more than the number: performance became observable. You could see which endpoint was slow instead of guessing.

The tool that made client bugs reproducible

The recurring pain was not an outage, it was a category of ticket. A customer reports something broken in production, and the content that triggers it is a book with dozens of nested documents that only exists in their environment. You cannot debug what you cannot reproduce, and recreating that structure by hand was hours of work for a single bug.

So I built an internal migration tool that replicates content assets, books and their nested documents, across environments. Pull the real structure into a safe environment, reproduce the bug in minutes, fix it against the actual data.

It changed the shape of the work. Debugging stopped being archaeology.

That problem stayed with me: I later wrote mongo-cascade-migrator as a general purpose version of the same idea, cloning MongoDB documents with their cascade of references.

Search and caching

Content discovery ran on ElasticSearch, with Redis caching in front of the read paths that did not need to be recomputed on every request. I also contributed to the Vue.js frontend where backend changes surfaced directly in the interface, which is usually where you find out that your API shape is inconvenient to consume.

What I took from it

Two years of fully remote work across a five hour timezone gap, before remote was the default. It taught me to write decisions down properly the first time, because the cost of an ambiguous message is not a follow-up question, it is a lost day.