One API per dashboard, and why a short TTL beats a long one
Nine dashboards, data owned by another system, and a frontend that shouldn't have to care. Here's how an aggregation endpoint and a short-lived cache keep them fast and current.
Backend, payments, and scaling lessons from production work, each with a figure that shows the idea at a glance.
Short engineering write-ups from production work on .NET, ABP.io, Redis, and payment systems: idempotent Request to Pay flows, Redis connection pool exhaustion, EMV QR TLV encoding, bulk push notification scheduling, and CI/CD that promotes one image from UAT to production. Each note ties back to a case study on the work page.
6 notes, 4 topics
LinkedIn UpdatesLinkedIn UpdatesShowing all 6 notes
Nine dashboards, data owned by another system, and a frontend that shouldn't have to care. Here's how an aggregation endpoint and a short-lived cache keep them fast and current.
A request that reaches the customer as a push notification and a USSD prompt at the same time needs one rule above all the others: it can only be paid once.
If production runs an image that UAT never saw, you are testing one thing and shipping another. Here's the pipeline change that fixed it for the telco agent apps.
Our Redis outages looked like a capacity problem. They weren't: every request was opening its own connection. Here's the multiplexing fix that kept the Mixx Tanzania app up at peak.
An EMV QR code is a string of tag-length-value fields with a checksum at the end. Here's how the format works, static and dynamic, and how to build one in C#.
Chunked reads, a semaphore of two, and one retry pass at the end: the design behind a scheduler that sends 700-800k notifications per run in 6-8 minutes.
Short write-ups on problems I run into while building payment and backend systems. Follow along, or tell me what you'd like me to write about next.