Full Width [alt+shift+f] Shortcuts [alt+shift+k]
Sign Up [alt+shift+s] Log In [alt+shift+l]
1

On over-engineering; Architecture Edition

from Eliran Turgeman [alt+shift+b] in programming

I recently wrote about over-engineering and striking a good balance between making your code “too” future-proof and not making it future-proof at all. Some time later, I realized it was missing a critical perspective. I hadn’t addressed over-engineering from an architectural point of view, so this post is dedicated precisely to that. Let’s talk about a decision I made for Collecto, my side project. Collecto is still in its early stages, and like most early-stage projects, its future is uncertain. It could grow into something big—or not. That’s where architectural decisions get tricky. You don’t want to overengineer and waste time, but you also don’t want to under-engineer and regret not laying a solid foundation. So what’s the problem? Collecto is a forms-backend service, meaning it handles the creation, management, and processing of forms data for applications. I wanted to add the ability to send emails on certain events. For example, when a new user signs up for your form, you might want to send them a welcome email. The simplest solution? I could write a new service responsible for sending emails and call it directly wherever needed— for example, right after a user signup is saved to the database. This approach works, is easy to set up, and introduces no additional overhead. However, it results in tight coupling, making future changes more challenging. If tomorrow I want to also send a notification to the form owner when they receive a new subscription, I would have to keep adding more responsibilities to the form service code. This bloats the core service, which should ideally focus solely on CRUD operations for forms. On the other end of the spectrum, I could go all-in and build a distributed pub/sub system with a service bus like RabbitMQ or Azure Service Bus. This would give me scalability, decoupling, and all the good stuff. But it’s also a massive investment in time and complexity for a project that doesn’t need it, yet. I didn’t like both options, so I...
10th Dec 2024

Stay updated

Get a weekly newsletter with the top 5 articles worth reading every week.

More from Eliran Turgeman

My productivity rules

A friend asked me for some study/productivity tips, and I figured the most productive thing I can do is write a post about it. That way, it might help more people too. So here we go. Before we start, there are two things you need before any productivity advice will work: Be introspective. Be honest with yourself. My productivity rules Plan your day the night before Don’t leave decisions for your foggy, maybe lazy, morning self. Here’s the loop: wake up → review study plan → study → write down the plan for tomorrow → sleep → repeat. Check your energy during the day If you just ate and feel sleepy, don’t force deep study. Take a 30–60 minute break - nap, walk, exercise, or scroll your phone a bit, then come back refreshed. You can also take micro-breaks: finish a chapter, grab water or a piece of chocolate, and get back to it within five minutes. Don’t lie to yourself about effort Setting goals is great, but be honest about how hard you actually worked. You can check all the boxes, feel proud, and still know deep down that you took it easy. That’s fine sometimes, we all need rest days - but don’t confuse that with an intense study session. Review your day When you plan tomorrow’s tasks, reflect on today. Did you actually do what you set out to do? If not, why? Maybe your goal was too ambitious, or maybe you just spent too much time gaming. Either way, learn from it. There’s always room to improve, if the goal really matters to you. Limit distractions Put your phone on silent and out of reach. If you study on your computer, close anything that might tempt you, and even hide shortcuts to distracting apps. When I was in uni, I played a ton of League of Legends. The desktop icon was staring at me every time I opened my laptop — so I buried it under three folders. Sounds dumb, but it worked. A few more things Get good at breaking big goals into small tasks. If your goal is to pass an exam, start by mapping out all the smaller steps that’ll get you there. Spread them out over time, with a bit of buffer. Plans will change — that’s fine — but you should always know where you stand and adjust as you go. And one more time, because it’s that important: don’t lie to yourself. If you spent four hours on TikTok, felt bad, then studied a little to compensate — that’s not a “productive” day. Call it what it is. It’s okay to have those days, you’re human — just plan for them instead of pretending they didn’t happen. I believe that much of the productivity advice online includes some stupid ceremonies and whatnot, just do what you feel works for you. I think the ability to introspect, being honest with yourself and improving over time is all that matters. Take whatever breaks you need, in whatever order you want. You don’t need a fancy journal to write your tasks, open a txt file. You don’t need a perfect system, just something simple that works for you.

8th Oct 2025 • 1 votes
Fighting subscription fatigue with vibe-coding

Most people solve their subscription fatigue by canceling Netflix. I solved it by vibe-coding my own workout app instead of paying another SaaS. Two weeks ago, I decided to get serious about my workouts again and start logging them. I looked for an existing solution that has the following: create workouts log sets, reps, and weights a calendar to track consistency simple enough. Free apps were crammed with ads. Paid apps had bloated features I didn’t want. Both annoyed me. Before vibe-coding, I’d either tolerate ads or pay. Now there’s a third option - build my own. Of course, you could always build your own, but pre-vibe-coding it would take much more time to be worth it. How did I choose the vibe coding platform? I logged into loveable, base44, bolt, and wrote the following (imperfect) prompt 1 2 3 4 5 6 7 I want to create a personal webapp for managing my own workout routines (kind of a workout logger) I want to be able to define "workouts" - collection of exercises including sets and reps I want to be able to track which workout i did on which day - calendar view I want to be able to log the weights I did for every exercise in every set. I want my workout templates to be a simple collection of exercises that are plaintext - don't create some kind of an exercise library.. i just want to type the exercise name myself make it stateful, including a db connection to store all the relevant data. Whichever tool gave me the best first shot, I ran with. This time it was Loveable. Iterating With that one-shot starting point from loveable, I published it, and went to my first workout at the gym, all excited and ready to use what I built. First workout: I needed notes for exercises. Another: supersets. Each time I wrote it down, went home, and 15 minutes later I published a new version with loveable. After two weeks of using this app at the gym and doing tweaks, the app feels solid. On my last iteration, I added a badges/achievement page, and a github-like consistency widget that looks cool I hope will help me stay on track and be consistent. Sharing Friends wanted to try it too - the problem? I didn’t make it secured by sign-in, I thought I only need it for myself, and even if someone’s going to find this weird loveable URL, they could only see my workouts - who cares… But of course for my friends I’ll write one more prompt - and so I added Supabase auth within minutes. Final Thoughts This post isn’t about showing off my little workout logger anyone could make in a few hours prompting. It’s about how easy it is today to scratch your own itch. You build the exact features you need, when you need them. No ads, no bloat, no adapting to someone else’s UX. Just something comfortable and fun to use. It’s never been easier to bring your ideas to life, small or big.

16th Aug 2025 • 1 votes
Why sharing a redis cluster across services is asking for trouble

If there’s one pattern I’ve seen across multiple companies, from scrappy startups to big corps, that causes endless headaches, it’s this: a single cache cluster shared across services. I recently shortly wrote about my lessons from building and maintaining distributed systems at scale, and the first point that came to mind is exactly this - it starts with an excuse of simplicity, “we already have a cache cluster up and running, let’s just make this other service use it, no need for more infra”, and ends with a confused on-call engineer trying to debug which services were affected by the last keys eviction. So I want to double down on this idea and explain in more detail why it becomes a nightmare once your system scales. One eviction policy You got different services each throwing keys at the same redis cluster. A sudden spike/bug just caused a dramatic increase in cache writes - your cluster wasn’t ready for this, it hits maxmemory and now different keys are being removed based on your eviction policy. What’s the problem? there’s no isolation - service A caused the max memory, and now service B, C, D also pay the price - their keys are being removed as well from the cluster, and could affect the latency, and correctness of other flows of your system. Monitoring is harder Our metric fires up — we see a drop in hit rate on the cluster. Which service is causing it? Who’s affected? Instead of thinking about one service, you’re now mentally juggling everything across the entire system. More noise, less clarity. Although monitoring is harder, you could set up application monitors that you send once you write/read from the cache, based on the prefix of the key. potentially if you are organized and each service that uses the cluster has a unique prefix and you can easily identify between the hit rates of different prefixes - that’s great, but you have to work to get there. Debugging is harder This ties back to my first point about the eviction policy. You had 10m keys. something happend. now you got 5m. The effect on the services is really hard to trace. One service might have lost 100k keys, and you barely see a difference in its monitors, but it doesn’t mean your users are not feeling something is off, maybe today the are waiting a bit more for the page to load, but it’s not too long to hit your monitors thresholds. In that case, if you didn’t have a monitor on the cache cluster for keys eviction, you might be totally blind..”oh I see a slight latency increase here, but no monitors popped - guess all is well” So, never use a shared cache cluster? No, that’s not the lesson here. In some cases it is totally fine to use a single cache cluster. For example: You don’t really have a lot of traffic read/written to the cache so most of it is free anyway You store shared static data (for example, feature flags) Also note that some of the points I was making here against using a single cache cluster, can be somewhat mitigated by having good monitoring set in place. For example, having a defined prefix for the cache key per use-case, per service, and publishing metrics in the application level so we have observability to which type of keys (by prefix) are experiecning a low hit ratio. But on the other hand, tracking keys eviction is harder to monitor, since it’s not initiated by your system. Anyway, I hope you get the point. If you are getting started, a single cache cluster is totally fine. Otherwise, spin up another cache cluster, and sleep better at night. 🚨 Become a better software engineer. practice building real systems, get code reviews, and mentorship from senior engineers. Get started with 404skill

1st May 2025 • 1 votes
Escaping the local maxima

when i was a student, everything was simpler. grind leetcode. build projects. get an offer. i knew the salaries. i knew what “winning” looked like. it was a somewhat straight line from broke student to backend engineer at a top company. and i did it, i 10x my life in the span of 4 years. five years in. and honestly? it’s… fine. it’s more than fine. but it also feels like i’m stuck on a plateau. the growth feels logarithmic. the peak that isn’t the peak things are good, but i can’t stop feeling like i want more, even though i am comfortable. i look back at the student version of me, and i see hunger. direction. i look at me now and i see someone who’s tried a bunch of things: built products that barely anyone used started a newsletter, got some nice traffic, but it didn’t stick thinking about podcasts, courses, maybe a dev agency? dreaming of 10x-ing my life again, but not sure where to invest my time. when i was younger, the path was obvious. now it’s all vague, i could do anything. do i go all-in on indie hacking? live off my rsu’s for a few years and just build? try again with another product? double down on the blog? start a podcast? well, the next level doesn’t seem to come with an instructions book. escaping means risking the fall as a cs student you learn that escaping a local maxima usually means exploring a few downs to find a higher maxima. well, applying it to life is scary. what if i lose everything i worked hard to build? i am no longer a student living off of scholarships, i have more obligations. and also, the scariest part of all is what if this is the best it gets? i prefer to be positive and believe there’s another jump out there. something worth building. something that might actually shift my trajectory again. i just haven’t found it yet. but i’m looking. 🚨 Become a better software engineer. practice building real systems, get code reviews, and mentorship from senior engineers. Get started with 404skill

5th Apr 2025 • 1 votes

More in programming

A new home for all my apps: apps.chofter.com

Say hello to apps.chofter.com, the new home for everything I build. The speed at which I ship new things has massively increased with the advent of AI, and I’ve been encouraged by the fact that, as I approach my sixth decade, new ideas for useful & fun things to build still come at me apace. These no longer fit on my personal homepage, which is a combination of work experience, interests, things I made long ago that are no longer relevant (but still interesting), and of course, the many apps & tools I have out there in the wild right now. The site was 100% built using Claude Code, which did an amazing job of inspecting all the various websites, app stores and code bases and constructing a site in 30 minutes or so. I had to push it to make the site more SEO friendly, pre-rendered to HTML rather than over relying on client side rendering, but that was it. So there we go, enjoy the delightful and hopefully useful apps that I’ve already built and will continue to build in the future

2 hours ago • 1 votes
SumatraPDF new features: March 18, 2026

New in the SumatraPDF pre-release builds: DDE commands accept arguments Commands sent via DDE can take arguments, the same as in custom shortcuts (#5383). Loading message in tab While a document loads, its tab shows a “loading” message instead of the home page (#5385). Install 32-bit on 64-bit Windows The installer lets you install the 32-bit version on 64-bit Windows (#5379). Changes for this day · Full changelog

22 hours ago • 1 votes
An Update on Orion for Linux and Windows

Kagi is ending development of Orion for Linux and Windows and open-sourcing both so the community can carry them forward. Our small team will now focus fully on making Orion for macOS and iOS faster, more stable, and more capable.

yesterday • 1 votes
Clip of me singing Despard in Ruddigore in 2013

A clip of me singing a funny song from Gilbert and Sullivan’s Ruddigore back in 2013

yesterday • 1 votes
How and Why fork() Uses Copy-on-Write

In this video, we look at why fork() needs copy-on-write, how it works inside the kernel, and a memory usage problem that Instagram encountered with Python.

yesterday • 1 votes
📚 BoredReading

You seem to be enjoying this.

Join free to unlock everything.

Create free account

Already have an account? Sign in