Engineering

Caching Strategies

I implemented caching layers to reduce latency and database load across systems serving many concurrent users.

See its threads in the world

Used on

Stories where it mattered

2021 · Hybrid.Chat conversational platform

High availability for a bot runtime that insisted on being in memory

Situation
The chatbot platform's runtime holds conversation state in memory, so under high availability any pod restart dropped live conversations.
Task
Survive pod churn without rewriting the conversational runtime the product was built on.
Action
I checked alternative frameworks, found the same limit, and kept the runtime: sticky sessions, state persisted to Mongo, and Redis pub/sub to close duplicates.
Result
The platform ran multi-container with state surviving restarts, and the design documented its failure modes, including those the fix introduced.
View in the world
2023 · Hybrid.Chat conversational platform

Wanting to build it in house and buying instead

Situation
The bot platform needed web push notifications, and my instinct was to build it in house for future flexibility.
Task
Decide between building and buying, separating engineering reasons from personal preference.
Action
I wrote down what I wanted from in-house, weighed it against what the release needed, and recorded the preference and the decision against it.
Result
We shipped on the vendor, and the recorded trade-off made later customisation questions easy to answer.
View in the world
2023 · Omnichannel agent inbox

Taking a component out of the stack instead of adding one

Situation
A messaging product ran Keycloak for identity, yet users, roles and organisations already lived in Dgraph, so every write landed twice.
Task
Remove the dual write and its compensating code, and get to one store of record.
Action
I checked which Keycloak features were used, found none beyond authentication, which NestJS covers, and wrote a decision record proposing its removal.
Result
The dependency and its rollback logic came out, leaving the backend with a single store of record.
View in the world
2024 · Kray.AI search and document assistant

One model for everyone, or one per customer

Situation
A document assistant for a fleet operator needed an architecture, and one model trained on every vessel's documents was the assumed default.
Task
Lay out the real trade-offs of cost, latency and access control instead of just picking one.
Action
I wrote both options out for client and team: one shared model versus one model per vessel, with pros, cons and the replica arithmetic.
Result
The partitioned design went forward, with the loss of cross-fleet questions accepted openly.
View in the world

Goes with

RedisDistributed SystemsObservabilityAPI DesignFault ToleranceRate Limiting

Throw me a paper plane

Write a line; I’ll find it in my inbox.

✉ Email▤ Résumé☎ Call✆ WhatsAppLinkedIn · GitHub · QR in the world