In high-volume messaging applications (like WhatsApp, Telegram, or webchats), it's common for a user to send multiple messages in sequence (message A followed by message B within a short interval) before the first response is generated and delivered.
This is a technical case study based on a real-world integration scenario with the Google Sheets API, focused on solving quota scarcity and high error-rate problems. In the original scenario, direct load requests quickly blew past the Google ecosystem's limit (300 requests/minute), triggering cascading failures (HTTP 429 - Too Many Requests). To solve the bottleneck, a mock service in Go (sheets-mock-api) was built to faithfully reproduce the real limits, and the Graceful Degradation with Redis pattern was implemented in the main Laravel application (main-service-api).
This is a resilience case study: the payment-service simulates a real memory leak (not artificial latency/error) that grows until it hits the container's memory limit, enters a crash-loop (OOM-kill + automatic restart) under sustained load, and the order-service evolved, branch by branch, to handle it — retry with exponential backoff and jitter, circuit breaker, and bulkhead.
Thoughts on technology, web development and software engineering.
In high-volume messaging applications (like WhatsApp, Telegram, or webchats), it's common for a user to send multiple messages in sequence (message A followed by message B within a short interval) before the first response is generated and delivered.
This is a technical case study based on a real-world integration scenario with the Google Sheets API, focused on solving quota scarcity and high error-rate problems. In the original scenario, direct load requests quickly blew past the Google ecosystem's limit (300 requests/minute), triggering cascading failures (HTTP 429 - Too Many Requests). To solve the bottleneck, a mock service in Go (sheets-mock-api) was built to faithfully reproduce the real limits, and the Graceful Degradation with Redis pattern was implemented in the main Laravel application (main-service-api).
This is a resilience case study: the payment-service simulates a real memory leak (not artificial latency/error) that grows until it hits the container's memory limit, enters a crash-loop (OOM-kill + automatic restart) under sustained load, and the order-service evolved, branch by branch, to handle it — retry with exponential backoff and jitter, circuit breaker, and bulkhead.
Water Drink (Hidratação Diária) is a mobile app built with React Native and Expo to log water intake, calculate personalized goals, and remind users to stay hydrated.
Details on onboarding, home screen, exercise-based goal boosts, favorites, achievements, notifications, settings, tracking, and the Android widget of the Water Drink (Hidratação Diária) app.
Discover how to design a Flow Service capable of running complex automations on an omnichannel platform without blocking queues, while maintaining high availability, scalability, and low coupling. In this article we explore a state-based architecture, RabbitMQ, independent modules, and asynchronous execution.
After identifying the conversation and the automation flow associated with the channel, the Flow Service takes over control of the entire automation execution.
The Validation Service receives incoming events from various channels and ensures they are valid before forwarding them to the other microservices (support, chatbot, CRM, analytics, etc.).
Circuit is Nexo's first module: it lets companies create and manage virtual running championships for their customers, with automatic result tracking via Strava webhooks.
A case study comparing availability and latency of CPU-bound and memory-bound microservices, with and without retries, circuit breakers, load balancing, and scaling.