Article of the day
Rate limiting isn't just about picking an algorithm. There are three problems to solve, how you count requests, what identity you rate limit on(API key, userId), and distributed coordination. Get any one of these wrong and you'll either block legitimate users or leave the door open for attackers.
A common mistake is rate limiting by IP alone. It works until a large company sits behind a NAT where hundreds of employees share the same public IP. One busy user can cause everyone else to hit the limit even though they're behaving normally. For authenticated APIs, user IDs or API keys are usually much better keys than IP addresses.
For the algorithm itself, Token Bucket is a great choice when clients need to send short bursts of requests while staying within an average rate over time. Sliding Window Counter provides more consistent enforcement without storing every request, making it a good fit for high-traffic APIs.
In distributed systems, every server needs to enforce the same limits. That's why many production systems store rate limit state in Redis and use Lua scripts to make the check-and-update operation atomic. This prevents race conditions where multiple servers could allow more requests than intended.
Read the full article 👉 [ LINK ]
@devwitheyob
#TechVibe #RateLimiting #SystemDesign #ArticleOfTheDay
Rate limiting isn't just about picking an algorithm. There are three problems to solve, how you count requests, what identity you rate limit on(API key, userId), and distributed coordination. Get any one of these wrong and you'll either block legitimate users or leave the door open for attackers.
A common mistake is rate limiting by IP alone. It works until a large company sits behind a NAT where hundreds of employees share the same public IP. One busy user can cause everyone else to hit the limit even though they're behaving normally. For authenticated APIs, user IDs or API keys are usually much better keys than IP addresses.
For the algorithm itself, Token Bucket is a great choice when clients need to send short bursts of requests while staying within an average rate over time. Sliding Window Counter provides more consistent enforcement without storing every request, making it a good fit for high-traffic APIs.
In distributed systems, every server needs to enforce the same limits. That's why many production systems store rate limit state in Redis and use Lua scripts to make the check-and-update operation atomic. This prevents race conditions where multiple servers could allow more requests than intended.
Read the full article 👉 [ LINK ]
@devwitheyob
#TechVibe #RateLimiting #SystemDesign #ArticleOfTheDay
❤2
Take a look at this client-side code. When the API returns a rate limit response, the backend sends a
The reason is simple. If every client uses only exponential backoff, they'll often retry at nearly the same time, creating a thundering herd that can overwhelm the server again. Full jitter adds a random delay, spreading retries more evenly and smoothing out traffic spikes. Always use the
@devwitheyob
#TechVibe #RateLimiting #CodeSnippet #go
Retry-After header, and the client waits for that duration before trying again. One thing you might notice is the use of jitter. Why do we add randomization here?The reason is simple. If every client uses only exponential backoff, they'll often retry at nearly the same time, creating a thundering herd that can overwhelm the server again. Full jitter adds a random delay, spreading retries more evenly and smoothing out traffic spikes. Always use the
Retry-After header when it's provided; otherwise, calculate the delay yourself using exponential backoff with jitter.@devwitheyob
#TechVibe #RateLimiting #CodeSnippet #go
❤1👏1
TechVibe
Photo
They liked it guys
Also was on interview and it was good they liked how I approach problems and deliver in short amou t of time
@devwitheyob
#TechVibe #project
Also was on interview and it was good they liked how I approach problems and deliver in short amou t of time
@devwitheyob
#TechVibe #project
🔥11❤1
"Thinking of talent as innate makes our world more manageable, more confortable. It relieves a person of the burner of expectation"
From Limitless book.
@devwitheyob
#TechVibe #books #random
From Limitless book.
@devwitheyob
#TechVibe #books #random
My linkedin engagement for the past 7 days
Let's connwct and help me grow my acc on linkedin guys🙏, this is my 4th acc, they keep banning my accounts 😭😭
My LinkedIn: https://linkedin.com/in/eyob-simachew
@devwitheyob
#TechVibe #linkedin
Let's connwct and help me grow my acc on linkedin guys🙏, this is my 4th acc, they keep banning my accounts 😭😭
My LinkedIn: https://linkedin.com/in/eyob-simachew
@devwitheyob
#TechVibe #linkedin
👍5
Article of the day
Microservices don't mean you need ten different servers from day one. Most teams start by splitting a large backend into smaller services while still running everything on a single VPS with Docker Compose. Each service has its own Docker image and container, and services communicate over HTTP, gRPC, or a message broker like RabbitMQ or Kafka. This already gives you independent deployments, better code organization, and the ability to update one service without rebuilding the entire backend.
As traffic grows, you start moving services onto their own VPSs based on their resource needs. An AI service might need a machine with more CPU and memory, while an authentication service can stay on a much smaller server. Shared infrastructure such as PostgreSQL, Redis, and RabbitMQ is also commonly moved to dedicated machines so they aren't competing with application services for resources. This approach lets you scale only the parts of the system that need it instead of scaling everything together.
A good migration to microservices is usually gradual. Start by identifying clear business domains like authentication, users, payments, notifications, or courses, then extract them one at a time into separate services. Once a service is independent, it should eventually own its own database instead of sharing one with every other service. That prevents services from directly changing each other's data, reduces tight coupling, and allows each database to be optimized, scaled, and maintained independently. The goal isn't to split everything as quickly as possible, but to create boundaries that make the system easier to develop, deploy, and scale over time.
Read the full article 👉 [ LINK ]
@devwitheyob
#TechVibe #Microservices #Docker #SystemDesign #ArticleOfTheDay
Microservices don't mean you need ten different servers from day one. Most teams start by splitting a large backend into smaller services while still running everything on a single VPS with Docker Compose. Each service has its own Docker image and container, and services communicate over HTTP, gRPC, or a message broker like RabbitMQ or Kafka. This already gives you independent deployments, better code organization, and the ability to update one service without rebuilding the entire backend.
As traffic grows, you start moving services onto their own VPSs based on their resource needs. An AI service might need a machine with more CPU and memory, while an authentication service can stay on a much smaller server. Shared infrastructure such as PostgreSQL, Redis, and RabbitMQ is also commonly moved to dedicated machines so they aren't competing with application services for resources. This approach lets you scale only the parts of the system that need it instead of scaling everything together.
A good migration to microservices is usually gradual. Start by identifying clear business domains like authentication, users, payments, notifications, or courses, then extract them one at a time into separate services. Once a service is independent, it should eventually own its own database instead of sharing one with every other service. That prevents services from directly changing each other's data, reduces tight coupling, and allows each database to be optimized, scaled, and maintained independently. The goal isn't to split everything as quickly as possible, but to create boundaries that make the system easier to develop, deploy, and scale over time.
Read the full article 👉 [ LINK ]
@devwitheyob
#TechVibe #Microservices #Docker #SystemDesign #ArticleOfTheDay
🔥3❤1
When I finished high school, my father took me on a trip into the countryside, and we visited over 8 different places. I learned a lot about how people live, what excites them, our culture, and many memories.
We also saw different natural places. I promised to make this kind of long trip at least every 3 years, but currently, moving freely is not something you can do, especially in the current situation.
I really wish things settle down and I will make the same kind of trip right after I graduate.
@Ihaveadream19
#trip
We also saw different natural places. I promised to make this kind of long trip at least every 3 years, but currently, moving freely is not something you can do, especially in the current situation.
I really wish things settle down and I will make the same kind of trip right after I graduate.
@Ihaveadream19
#trip
❤11
Article of the day
The tool list alone was 1.2 million tokens, 6x past the model's 200K-token context window, before it read a single prompt. A microservice exposes 2400 REST endpoints. The naive MCP spec approach generates one tool per endpoint, and that tool-list payload is what burns. We shipped this exact integration on a production agent platform and rolled it back within hours.
Read the full article 👉 [ LINK ]
@devwitheyob
#ArticleOfTheDay #MCP #SystemDesign
The tool list alone was 1.2 million tokens, 6x past the model's 200K-token context window, before it read a single prompt. A microservice exposes 2400 REST endpoints. The naive MCP spec approach generates one tool per endpoint, and that tool-list payload is what burns. We shipped this exact integration on a production agent platform and rolled it back within hours.
Read the full article 👉 [ LINK ]
@devwitheyob
#ArticleOfTheDay #MCP #SystemDesign
Article of the day
The planner estimated 200 rows. The actual count was 4.2 million. A dashboard query that loaded in 800 ms at launch now takes 12 seconds on 8 million rows. EXPLAIN ANALYZE shows a Nested Loop over a Seq Scan; a missing composite index on (tenant_id, created_at) turned a 2 ms Index Scan into a full table scan. We debugged this exact regression on multiple production teams.
Read full article 👉 [ LINK ]
@devwitheyob
#ArticleOfTheDay #backend #PostgreSQL
The planner estimated 200 rows. The actual count was 4.2 million. A dashboard query that loaded in 800 ms at launch now takes 12 seconds on 8 million rows. EXPLAIN ANALYZE shows a Nested Loop over a Seq Scan; a missing composite index on (tenant_id, created_at) turned a 2 ms Index Scan into a full table scan. We debugged this exact regression on multiple production teams.
Read full article 👉 [ LINK ]
@devwitheyob
#ArticleOfTheDay #backend #PostgreSQL
🔥1
Forwarded from BeniVerse
This is incredibly huge for us in Africa. DeepSeek V4 flash just launched a flash model that can compete with a top-tier ChatGPT model. Mind you, this is just a flash model, which means the Pro version is coming soon. The price difference is also huge. How are they making this efficient? https://api-docs.deepseek.com/quick_start/agent_integrations/codex
🔥4❤1
Article of the day
A customer gets charged for an order that never made it into the database. An order service publishes a Kafka event, then updates PostgreSQL. The database write fails after the event is already out, and a phantom order cascades downstream, inventory decremented, fulfilment notified, payment charged, all for an order that does not exist. Root-cause tracing is brutal: the event trail looks correct; the database is the one that disagrees. We debugged variants of this on multiple production Kafka-backed services.
Read full article 👉 [ LINK ]
@devwitheyob
#TechVibe #ArticleOfTheDay #SystemDesign #MicroService
A customer gets charged for an order that never made it into the database. An order service publishes a Kafka event, then updates PostgreSQL. The database write fails after the event is already out, and a phantom order cascades downstream, inventory decremented, fulfilment notified, payment charged, all for an order that does not exist. Root-cause tracing is brutal: the event trail looks correct; the database is the one that disagrees. We debugged variants of this on multiple production Kafka-backed services.
Read full article 👉 [ LINK ]
@devwitheyob
#TechVibe #ArticleOfTheDay #SystemDesign #MicroService
BackendBytes
Event-Driven Microservices in Go: Kafka, Sagas, and the Outbox Pattern
Reliable event-driven Go beyond connecting to Kafka: handling partial failures, duplicates, and distributed transactions safely.
🔥1
Need a toxic motivation to make my bed, anything on your side😁
Be my guest in the comments😭
@devwitheyob
#random
Be my guest in the comments😭
@devwitheyob
#random
TechVibe
Need a toxic motivation to make my bed, anything on your side😁 Be my guest in the comments😭 @devwitheyob #random
Motivation of the day😁
I'll tell you how risky life is
You're not gonna get alive
@devwitheyob
#TechVibe #random
I'll tell you how risky life is
You're not gonna get alive
@devwitheyob
#TechVibe #random
🤣1
TechVibe
Looks like someone's about to land a new job 😋 #random #job
Let me tell you how this happened.
This opportunity actually came from Upwork. The CEO found my profile, reached out, and we had a quick chat about my backend and automation experience. After that, we scheduled a technical interview, and then they gave me a take-home project.
I probably overdid it a bit. 😅 I didn't just build the features they asked for, I added tests, cleaned everything up, and even deployed it to production with additional features and even bought Gemini API to test it. After that, they had me walk through the code with their senior developers and answer a bunch of technical questions. The final round was a behavioral interview.
A few days later, they sent me an offer.
The company is US-based with a branch here in Addis. I'll be working as a Full-Stack & Automation Engineer. The schedule is from 5 PM to midnight, which actually works well with my university classes, and it's a hybrid setup. They also offered accommodation in the office so that I can work from there for the summer, so I'll be moving to Addis.
I was just getting started to enjoy my break with fam and friends but I gotta go back and hustle😭
@devwitheyob
#TechVibe #JobUpdate
This opportunity actually came from Upwork. The CEO found my profile, reached out, and we had a quick chat about my backend and automation experience. After that, we scheduled a technical interview, and then they gave me a take-home project.
I probably overdid it a bit. 😅 I didn't just build the features they asked for, I added tests, cleaned everything up, and even deployed it to production with additional features and even bought Gemini API to test it. After that, they had me walk through the code with their senior developers and answer a bunch of technical questions. The final round was a behavioral interview.
A few days later, they sent me an offer.
The company is US-based with a branch here in Addis. I'll be working as a Full-Stack & Automation Engineer. The schedule is from 5 PM to midnight, which actually works well with my university classes, and it's a hybrid setup. They also offered accommodation in the office so that I can work from there for the summer, so I'll be moving to Addis.
I was just getting started to enjoy my break with fam and friends but I gotta go back and hustle😭
@devwitheyob
#TechVibe #JobUpdate
🔥30❤3👏2🤯1