For some strangers who see us posting all day on Telegram, they think we get paid by view lol😂... we just doin' it for the love of the game😎

@devwitheyob
#TechVibe #TechVibe

Let me tell you something, fam...I promise this will be my last post for the day. 😁

All these successful (kinda successful) ppl you see online that you want to work with, ask for advice, or even get a job from haven't really been in the game for that long probably 2 yrs tops. Most of them just dedicated themselves to that thing. Imagine this, 2 years ago or even less, they were just like us.

I see people talking about them like they're doing something extraordinary. Stop that. It is pretty normal for hard working ppl to get a good income to create your own business. Start creating it yourself.

Hope it helps. Good night, fam. ✌️

@devwitheyob
#tips

About that hack I shared earlier... I just discovered another use case. 😄

You can connect your phone to a big speaker and use your phone as the microphone. That means you don't even need a dedicated mic to speak at an event.
It's also perfect for practicing public speaking or presentations.

Just connect to a big speakers you can aplify your sound from your phone. This is actually crazy.

@devwitheyob
#TechVibe #tips

Article of the day

Idempotency pattern

A payment request can time out even after the server has successfully processed it. Since the client can't tell whether the operation completed, it retries the request. Without idempotency, that retry can result in the customer being charged twice.

The solution is an idempotency key. For every payment, the client generates a unique identifier (typically a UUID) and sends it with the request. The server stores that key and the payment result within the same database transaction. If the client retries using the same key, the server returns the previously stored response instead of executing the payment again.

Idempotency keys shouldn't be stored forever. They should remain valid for at least as long as clients are expected to retry. A 24-hour TTL is a common default, balancing protection against duplicate requests with storage efficiency.

For production systems, every state-changing endpoint should require an idempotency key. Replayed requests should be checked before rate limiting since they're retries rather than new operations. Expired keys should be cleaned up periodically using a TTL, with an index on the expiration column to make cleanup efficient. The idempotency record should also maintain states such as PENDING, COMPLETED, and FAILED to handle retries and failure scenarios correctly. Finally, a reaper can safely remove requests that remain in the PENDING state beyond the expected request timeout, preventing abandoned operations from blocking future retries.

Read full article 👉 [LINK]

@devwitheyob
#TechVibe #ArticleOfTheDay #IdempotencyPattern #DistrubutedSystems

New Gemini 3.6 is here🔥

@devwitheyob
#TechVibe #Gemini #LLM

Article of the day

Composite Indexes, Equality-First Ordering & Covering Indexes

Most developers think adding an index automatically makes a query fast. In reality, the order of the indexed columns matters just as much as having the index itself. A poorly ordered composite index can force PostgreSQL to scan thousands of unnecessary entries before finding the rows you actually need.

A composite index stores multiple columns in a specific order. PostgreSQL always starts searching from the leftmost column, so the index should be designed to match how your queries filter data. This is known as the leftmost prefix rule.

When designing composite indexes, always put equality (=) conditions first and range (>, <, BETWEEN) conditions last. Equality filters drastically reduce the search space, allowing PostgreSQL to jump directly to a small subset of rows before scanning the requested range. Reversing this order often results in many unnecessary index scans and filtered rows.

A covering index goes one step further. By using the INCLUDE clause, PostgreSQL stores additional columns inside the index itself. If the query only needs those columns, the database can perform an Index Only Scan, returning results directly from the index without reading the table. This eliminates heap fetches, reduces disk I/O, and significantly improves query performance. For production systems, design indexes around your most frequent query patterns, not around individual columns. Verify every index with EXPLAIN ANALYZE, look for high Rows Removed by Filter, place equality columns before range columns, and use covering indexes for high-traffic read queries to eliminate unnecessary table access.

Read full article 👉 [ LINK ]

@devwitheyob
#TechVibe #ArticleOfTheDay #PostgreSQL #Indexing

brooooooo wth 😭

@selfmadecoder

🚀 Want Free AWS Training? Your Journey Starts This Friday!
We're excited to announce that attendees of our upcoming Cloud Blueprint: Navigating the AWS Solutions Architect Journey & Bootcamp Sneak Peek! session will have the opportunity to join an exclusive AWS Solutions Architect Bootcamp designed for our community.
🎯 What's in it for you?
✅ FREE AWS Solutions Architect Bootcamp training
✅ Access to a temporary AWS cloud environment for hands-on learning and experimentation
✅ Guided learning path and practical cloud experience
✅ Opportunity to learn alongside fellow community members
✅ Support in building real-world AWS skills
📢 Important: Attendance at this Friday's event is a prerequisite for bootcamp eligibility.
If you're serious about building cloud skills, earning AWS certifications, or pursuing a career in cloud computing, this is your opportunity to get started with the support of the AWS User Group Addis Ababa community.
🎙 Featuring: Simon Gebreselassie, Solutions Architect @ AWS
📅 Friday, June 26, 2026
🕕 6:00 PM EAT
💻 Online Event
During the session, we'll discuss the Solutions Architect journey, share details about the bootcamp roadmap, and explain how participants can qualify for the program.
Don't miss the first step toward your cloud career.
👉 Register
@AWSUserGroupAddisAbaba

Lol😂

@devwitheyob
#TechVibe #random

There is a new project on AfterQuery, you just need to upload a repo with good code quality

[ LINK ]

@devwitheyob
#TechVibe #AfterQuery #Jobs

Some people should understand this, fr😭

@devwitheyob
#TechVibe #Gumball

I literally forgot how fun it was watching Cartoon Network growing up.

I'm watching Gumball, and it's fire. I feel like we're the last generation that truly got to experience growing up with cartoons like this before this TikTok era. 😊

@devwitheyob
#TechVibe #nostalgia #cartoon

I think tenant isolation should be enforced in both the application and the database.

The application handles business logic and permissions, but the database should be the last line of defense. If a developer forgets a tenant_id filter or introduces a bug, RLS(Row Level Security) still prevents data from another tenant from being returned. Also every developer has to remember to put that where filter and that is risky

The performance cost of RLS is usually minimal with proper indexing, and the extra security is worth it. Most production SaaS systems use this, application-level authorization + database-level RLS. It's much safer than relying on the application alone.

@devwitheyob
#TechVibe #MultiTenant #databases #Security