Mehmet Ali Genc

Hiring in Amsterdam

2

Google vs. Google on the long context window contest: Another paper from Google introduced a novel Transformer architecture: Feedback Attention Memory (TransformerFAM), which adds a feedback loop (an RNN-like construct) at each layer of the model. For performance comparison, a fine-tuned version of TransformerFAM solves passkey retrieval perfectly up to 256K tokens. For Infini-attention, a fine-tuned version also solves it perfectly up to 256K tokens. Although another version of Infini-attention can solve it perfectly at 512K and 1M tokens, that same version couldn't solve it perfectly at 256K tokens or below, making the success at 1M tokens a bit weaker. #artificialintelligence #machinelearning #deeplearning

3

7 Must-Read System Design Case Studies: (every SRE & SWE should know these) I now make every new joiner go through these: 0. "Large-scale cluster management at Google with Borg" https://lnkd.in/eHD8E9N4 1. "8 Reasons Why WhatsApp Was Able to Support 50 Billion Messages a Day With Only 32 Engineers" https://lnkd.in/ecwNPNJ6 2. "How Cloudflare Was Able to Support 55 Million Requests per Second With Only 15 Postgres Clusters" https://lnkd.in/eevnrW3C 3. "How Amazon S3 Achieves 99.999999999% Durability" https://lnkd.in/ebsGK4NM 4. "How Uber Computes ETA at Half a Million Requests per Second" https://lnkd.in/e_3kFKCY 5. "How Tinder Scaled to 1.6 Billion Swipes per Day" https://lnkd.in/eqvh75sA 6. "How Does Netflix Work?" https://lnkd.in/eRQtxDnH What other studies should I include? ♻️ Repost for others to see 📕 Save for later 🔔 And follow Miko Pawlikowski 🎙️ for more!

57

87 Comments

NEW: It looks like the new AWS Lambda Sandbox code is written in Rust, and migrated off of Go. Previously, GODEBUG=inittrace=1 would reveal debug output from Go as it loaded the sandbox (and eventually your code). Now with RUST_BACKTRACE=full (and crash the runtime), you'll get a full stack trace (and GODEBUG does nothing). I suspect this is part of the rollout I mentioned earlier this year, with the newly updated Lambda Runtime API location. I haven't noticed any major performance differences, so I hope we'll see new features and capabilities as a result. Looking forward to the eventual reInvent talk where they discuss the rationale and results of this change!

481

17 Comments

𝐍𝐚𝐭𝐢𝐯𝐞 𝐇𝐓𝐓𝐏'𝐬 𝐢𝐧 𝐆𝐨𝐥𝐚𝐧𝐠! 💡 Another new and interesting article to dive into around Golang! https://lnkd.in/ea5gYBVt As always please leave any impressions and thoughts in the comments! 😁

22

1 Comment

Here are the slides for my GopherCon.EU talk: How to Win Frames and Influence Pointers https://lnkd.in/d7byRQfu #gopherconEU #golang

72

4 Comments

🌐 The CAP Theorem: A Must-Know for System Designers Distributed systems face an inevitable trade-off: you can only guarantee two out of three properties at the same time: 1. Consistency (C): All nodes see the same data simultaneously. 2. Availability (A): Every request gets a response, even during failures. 3. Partition Tolerance (P): The system continues operating despite network communication breakdowns. Understanding these trade-offs is critical when designing systems for scalability and reliability. Do you prioritize consistency for mission-critical data? Or availability for seamless user experiences? In the latest System Design Blueprint, I break down the CAP Theorem, explore real-world examples, and share how to make informed decisions for your architecture. 📖 Dive into the details here: https://lnkd.in/g35_zuSP #SystemDesign #DistributedSystems #CAPTheorem #TechArchitecture #Scalability ⬳ If you liked this post: 🔔 Follow Ashish Singh ♻ Repost to help others find it 💾 Save this post for future reference

1

Are you striving for that Staff Engineer title but feeling stuck? You're not alone! Many talented software engineers face common hurdles that can derail their promotion journey. In our latest post, we explore the six key reasons why engineers often miss the mark and how you can overcome these challenges. Don’t let these pitfalls hold you back! Find out how you can develop the essential behaviours to unlock your potential! #SoftwareEngineering #CareerGrowth #StaffEngineer #TechLeadership #EngineeringSuccess #ProfessionalDevelopment Piero Sansone  Sam Elderfield

1

"Blazing Fast: Uber Serves 40 Million Requests per Second, Slashing CPU Cores by 95% from 60K to Just 3K, with Integrated Cache" 🚀 Don't Just Band-Aid Your Performance: Cache Like a Pro 🛠️ Cache is every developer's first line of defense against sluggish apps. But simply throwing a cache at a problem is like slapping a bandage on a gushing wound. It might offer temporary relief, but it won't fix the underlying issue. Uber’s epic struggle: While trying to make their apps faster and able to handle more users while stuck with old-fashioned storage. When there's suddenly a massive increase in people wanting to read data, it pushes them right to the edge of disaster. ❌❌ A BIG TECH HURDLE❌❌ Solution: Docstore comes to the rescue. Beyond the Quick Fix: 1.DocStore Query patterns - It turned out that more than 50% of the queries coming to Docstore are ReadRows requests. Build what’s required and what makes sense. 2.Bypassing Cache - Bypassing the cache in Uber's microservices ensures strong consistency for critical flows like retrieving items in an eater's cart, while leveraging cache for less critical tasks such as fetching a restaurant's menu. 3.Brilliant Cache Invalidation Strategy using CDC and Flux - Cache Invalidation is one of the critical problems in Software Development. This strategy ensures cache consistency within seconds, preventing the risk of uncommitted transactions affecting cache integrity. 4. Special Redis Codec for Row Reads: Unique row values in MySQL are cached in Redis using a special codec to ensure compatibility. This facilitates sharing cache resources across databases while maintaining data isolation. 5. Cache Warming and Cross-Region Replication: Instead of using inbuilt Redis replication, Leveraging the Query Engine for Cross-Region Replication ensures consistency. 6. Sharding Differently: Sharding Redis clusters differently from the database scheme optimizes caching for diverse data access patterns, enhancing overall system performance and scalability while resolving potential inefficiencies in cache management and data retrieval. 7. Adaptive Timeouts: Optimizing Redis Performance with Dynamic Timeouts. This prevents issues like premature failures or excessive latencies. Percentile latency ranges: P75 latency decreases by 75%, and P99.9 latency drops by over 67%, all while curbing latency spikes. ⏱️ As of the current date, CacheFront supports over 40M requests per second across all production Docstore instances, with continuous expansion. 📈 Blog Link : https://lnkd.in/ghvAY3_Z This is undoubtedly one of the finest reads I've encountered on distributed cache systems. I highly recommend giving it a read. 📚 Big Thanks to Preetham Reddy Narayanareddy Afshin Salek Piyush Patel Zurab Kutsia Eli (Oleg) Pozniansky #Systemdesign #distributedcache #cache #p99latency #systemdesign #design

21

1 Comment

Scalability! But at what cost? This paper is an absolute classic because it explores the underappreciated tradeoffs of distributing systems. It asks about the COST of distributed systems--the Configuration that Outscales a Single Thread. The question is, how many cores does a big distributed system need to outperform some moderately-optimized single-threaded code running on your laptop? As it turns out, scalability often comes with an extremely high COST. The authors examine several graph processing systems--including some big names like Spark--and find that they need dozens to hundreds of cores to outperform a single-threaded program. Why is this the case? It's not because these distributed systems are badly designed, but because distributing computation is inherently inefficient for many problems. Fundamentally, a distributed system cannot rely on all processors sharing state, at least not efficiently. This is a big issue! In graph algorithms, it means servers need to expensively exchange data and eliminates a wide swathe of algorithms and optimizations that rely on shared state. In distributed databases, it means expensive coordination is required to distribute transactions to ensure participating servers have consistent views of data. Does this mean we shouldn't build scalable systems? Of course not! Many problems are well beyond the capability of a single server, no matter how optimized. But it does mean we should be mindful of the efficiency costs of scaling. As an aside, I think this kind of thinking is why Postgres is so popular, despite not being distributed. A large Postgres server can handle a vast amount of traffic (especially with read replicas, which can be cheaply maintained). You need a huge company or incredibly heavy workload to outscale that single server, and when you do, the alternatives come with huge tradeoffs!

177

10 Comments

I really like the clever pun "COST": it implies both performance overhead and hardware expenses. Plus, distributed systems also introduce higher maintenance costs. An example is microservices. While decomposing an application into hundreds of microservices and configuring loosely decoupled communication patterns might sound "scalable," it's worth asking: Do you really need that complexity? You might want to check if a simpler, monolithic system could meet your needs. For instance, by consolidating multiple microservices into a single service, Amazon's Prime Video team managed to reduce costs by 90%. (Blog by Adrian: https://lnkd.in/gedRZnsu) So, when designing your next system, weigh the true cost of complexity.

32

8 Comments

In my recent work with AWS SQS, I've come to appreciate the pivotal role queues play in high-scale, distributed systems. With our project handling over 100,000 requests, ensuring the top 3,000 are prioritized required a sophisticated approach, and AWS SQS delivered exactly what was needed. Queues are invaluable for managing data flow and executing asynchronous operations. The FIFO structure of SQS allows for precise order management, which is crucial when processing requests in a multi-threaded environment. This setup helps prevent bottlenecks and avoids duplication issues, ensuring that high-priority tasks are handled seamlessly. By leveraging AWS SQS's capabilities, we can distribute workloads efficiently across multiple consumers. This not only optimizes resource utilization but also maintains a high level of reliability and efficiency in our system. The experience underscored how essential queues are for building robust architectures that can scale gracefully and handle complex processing requirements.

5

Preparing for System Design Interviews? Here are some Must-Have Resources! System design interviews can feel like a complex maze, especially if you’re new to scaling architectures and designing large-scale systems. Over the past few weeks, I’ve been exploring resources to dive deeper into system design concepts, and I’ve found some fantastic platforms that can make this journey a bit smoother. Here are my top recommendations: 1. ByteByteGo by Alex Xu If you haven’t heard of ByteByteGo, you're in for a treat! ByteByteGo covers a wide range of topics on system design and architecture in a visually intuitive format. Alex Xu’s illustrations make it easier to digest complex topics like load balancing, database sharding, and caching strategies. It’s perfect for visual learners who want to get a high-level view without diving into overly technical jargon. The weekly newsletter is also a great resource for continued learning. 2. Educative.io – System Design Course Educative.io has an in-depth System Design course that’s highly interactive. This course breaks down each concept into easy-to-follow modules, making it great for both beginners and experienced developers. You’ll find comprehensive lessons on designing real-world applications like social networks, messaging systems, and content delivery networks. The hands-on, code-free approach also makes it ideal if you prefer practicing scenarios over coding during interviews. 3. LeetCode Design Questions LeetCode isn’t just about coding problems! They have a solid selection of design questions that often show up in top tech interviews. Practicing on LeetCode helps reinforce critical thinking for system design, especially under time constraints. Some of their design prompts, like designing a scalable file storage system or a URL shortener, are excellent for structured thinking and real-time problem-solving. Additional Tips: Focus on the Basics: Before diving into full systems, understand the building blocks: load balancers, databases (SQL/NoSQL), caching, messaging queues, etc. Practice Explaining: In interviews, clarity is key. Practice explaining your solutions and justifying your design choices. Mock Interviews: Consider pairing with a friend or joining online communities to simulate interview scenarios. Mock interviews can expose gaps and build confidence. By using a mix of visual, hands-on, and problem-based learning, you can create a comprehensive study routine that addresses multiple aspects of system design. Best of luck to everyone preparing! If you have any other favorite resources, feel free to share them in the comments below. Let’s help each other succeed! #systemdesign

4

🚀 Law as Code: Progress Update 🚀 Yes, the law can be expressed as code. And yes, LLMs can scale the translation en masse. I've reached the proof-of-concept stage with Json-Lawgic, and while the results are promising, key questions remain: 1️⃣ How accurate is the expression of laws? 👉 Subjective and evolving, but I've built an evaluation tool to begin testing this! 2️⃣ What are the practical applications? 👉 #RulesAsCode systems aren't new - this approach can be a means to build them more quickly. Furthermore, legal chatbots could call validated code as a tool to enhance their accuracy. 3️⃣ What's next? 👉 Feedback and collaboration so I'm not building in a vacuum! Huge thank you to Jason Morris and Damien Riehl for their advice and direction - this project is progressing a lot further than I expected thanks to your insights! How do I plan to enhance this project further? 🔧 Prototype a chatbot using encoded laws as tools   🔗 Build rule linking across statutes   📈 Scale with open-source LLMs (so OpenAI doesn't break my bank 💰!) To read more about my evaluation tool and the feedback I've received from experts on this subject, I've made a full blog post here: https://lnkd.in/ghD7p5je This project is open source, so feel free to check it out and give it a ⭐ to keep track as it grows: https://lnkd.in/gGV_b8pV To play around with what I have so far, here's the showcase: https://lnkd.in/gtTitarQ And if you have thoughts, feedback, or scathing criticisms - let's chat! #AI #ComputationalLaw #AccessToJustice #JsonLawgic #RulesAsCode

18

1 Comment

When reviewing code, I spend about 80% of my time on the contract: - the protocol buffer structure - GRPC method definitions - CRD's in our K8s Operator - DTO's in any REST API's 19% is spent on performance and security. Everything else doesn't matter since the customer only cares about: - Ease of use - Performance - Security - Capabilities.

34

5 Comments