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
There are actually different ways it can do that.
L4 load balancers work at the transport layer. They don't care about URLs, headers, or request bodies. They simply look at things like the source IP, destination IP, TCP/UDP ports, and protocol, then forward the entire connection to a backend server. Since they don't inspect or process the HTTP request itself, they're extremely fast and can handle millions of connections with very little overhead.
L7 load balancers work at the application layer. They terminate HTTPS, inspect the HTTP request, and make routing decisions based on things like the URL, headers, cookies, or even the request method. This is what allows requests like
That's why many production systems use both. An L4 load balancer sits at the edge and quickly distributes incoming connections, while L7 proxies behind it handle the smarter routing to the right application or microservice. It gives you the performance of L4 with the flexibility of L7.
@devwitheyob
#TechVibe #LoadBalancing #SystemDesignsig
L4 load balancers work at the transport layer. They don't care about URLs, headers, or request bodies. They simply look at things like the source IP, destination IP, TCP/UDP ports, and protocol, then forward the entire connection to a backend server. Since they don't inspect or process the HTTP request itself, they're extremely fast and can handle millions of connections with very little overhead.
L7 load balancers work at the application layer. They terminate HTTPS, inspect the HTTP request, and make routing decisions based on things like the URL, headers, cookies, or even the request method. This is what allows requests like
/api, /admin, and /images to be sent to completely different services even though they're on the same domain.That's why many production systems use both. An L4 load balancer sits at the edge and quickly distributes incoming connections, while L7 proxies behind it handle the smarter routing to the right application or microservice. It gives you the performance of L4 with the flexibility of L7.
@devwitheyob
#TechVibe #LoadBalancing #SystemDesignsig
❤2
Article of the day
One of the biggest reasons companies use gRPC is because it runs on HTTP/2. Unlike traditional HTTP/1.1, HTTP/2 allows multiple requests to travel over a single connection at the same time, reducing latency and connection overhead. It also supports streaming out of the box, so a server can continuously send updates to a client without opening new connections. That's why you'll often find gRPC powering communication between internal services like authentication, payments, AI inference, notifications, analytics, and other microservices. In many production systems, users interact with a REST API, but behind the scenes the services are talking to each other using gRPC for speed, reliability, and strong contracts.
Read full article 👉 [ LINK ]
@devwitheyob
#TechVibe #ArticleOfTheDay #SystemDesign
One of the biggest reasons companies use gRPC is because it runs on HTTP/2. Unlike traditional HTTP/1.1, HTTP/2 allows multiple requests to travel over a single connection at the same time, reducing latency and connection overhead. It also supports streaming out of the box, so a server can continuously send updates to a client without opening new connections. That's why you'll often find gRPC powering communication between internal services like authentication, payments, AI inference, notifications, analytics, and other microservices. In many production systems, users interact with a REST API, but behind the scenes the services are talking to each other using gRPC for speed, reliability, and strong contracts.
Read full article 👉 [ LINK ]
@devwitheyob
#TechVibe #ArticleOfTheDay #SystemDesign
❤3