FastAPI async concurrency benefits and limitations

Most AppSec programs have a blind spot. Python and npm dependencies? Tracked and patched. The C and C++ (C/C++) code powering your OS, firmware, and real-time systems? A blank space where the risk assessment should be. The problem isn't complexity. It's that most tools were built around the assumption that dependencies are declared somewhere machine-readable. In C/C++, that assumption fails. Alexandra Selldorff wrote about why and what getting it right actually looks like. https://lnkd.in/gDPd-KPQ

“App started breaking under the first production load test, even though the structure was correct.” Sometimes it’s not just about having a perfect application structure but about proper configuration tuning. That’s why I’m sharing another comparison, the earlier run without tuning (present on my profile) and the optimized version after tuning. At ~300 concurrent users, latency behavior degraded sharply, P99 reached ~2.7s and max spikes went up to ~7s, even though average response time still looked normal. The issue wasn’t the API structure or queries; it was how DB connections were being handled under concurrency. Pooling wasn’t properly enforced, so requests started queuing instead of executing in parallel. After fixing proper pool acquisition and ensuring each request correctly borrows/releases a connection, performance stabilized under the same load. Same system. Different behavior under pressure. #fastapi #python #backenddevelopment #postgresql

Rate limiting shouldn't come with a side of dependency hell. 🐍 Most Python rate limiters force a trade-off: either use a basic "fixed-window" script or pull in a heavy framework with a dozen sub-dependencies. This library was built to provide production-grade primitives with an emphasis on architectural flexibility and a zero-dependency footprint. The Technical Breakdown: ✅ 6 Algorithms: Beyond the standard Token Bucket. Includes Fixed/Sliding Windows and ADAPTIVE logic for dynamic scaling. ✅ 3 Backends: Native support for Memory and Redis, supporting both local-first and distributed environments. ✅ Zero Dependencies: Designed for high-security environments and lean builds. No requirements.txt bloat. ✅ Implementation: Clean integration via decorators for functions or middleware for web frameworks. If you are managing API quotas or protecting services from traffic spikes, the implementation details and performance focus are worth a look. https://lnkd.in/gnikRUHa #Python #SoftwareEngineering #SystemDesign #OpenSource #Backend #DistributedSystems

A common pattern in FastAPI code bases, one that is used in all example code, is to have a global variable which represents the SQL connection pool. The only problem with this pattern is making sure no class or function pulls it in directly, inline, where it can'tbe mocked. It's hard because so much of your code will depend on it. You'll quickly see why Java and C# used dependency injection as a standard design pattern. The question, then, is "Why?" And the answer is simply all your "unit" tests will now require a DB instance. Nothing says "fun" like watching all your test code blow up because someone forgot this (sometimes you're the someone.) Then you get to unravel layer upon layer of code. Claude can't do it all for you. #code #python

I’m pleased to share my recent project: a Distributed Caching System in Python, designed to improve application performance by reducing database dependency and network latency. The system leverages core data structures (LRU using HashMap and Doubly Linked List) along with object-oriented design principles to deliver efficient in-memory data retrieval. It also includes multi-node distribution, TTL-based expiration, REST API endpoints, and a Python SDK for seamless integration. Additional features such as rate limiting, logging, and a SQL-backed demo were implemented to simulate real-world backend scenarios. Through benchmarking, the system demonstrates a clear improvement in response time, with repeated requests being served from cache instead of querying the database. https://lnkd.in/d2-EGs7v This project was a valuable exercise in backend system design, performance optimization, and building production-oriented solutions. #Python #BackendEngineering #SystemDesign #Caching #APIs #SoftwareDevelopment #DistributedSystems

We are happy to announce the release of APyTypes v0.5 being available on pypi. APyTypes is a library with configurable fixed-point and floating-point scalar and array types for Python. It is written in C++ which makes the performance quite good. Think of it as NumPy, but with fully configurable data types. It is build with hardware design in mind. Hence, for fixed-point, there will not be any implicit quantization (expect for division, where we cannot really guarantee a finite result). It also means that you cannot compute, e.g., sin, but you can describe your approximation and use that and helpers to cast to float, compute the function, and cast back to the same format (which in practice will be a table-based implementation, which you can also generate code for, by the way). However, it should be noted that it is focused on simulating finite word length effects in a bit-accurate way and that it is independent of any hardware architecture (which is up for you to design, once you know how many bits you need). For a changelog see: https://lnkd.in/dreizmDF but there are new features, performance optimizations, and bug fixes. Highlighted new features are array comparisons and array slicing with boolean indices, so you can do things like a[a > b], pickling of the provided classes, and multi-threaded matrix multiplications. There is also a new playground where you can try it in the browser: https://lnkd.in/d-fZZTWX

LoraDB is now public. https://loradb.com/ It is a fast in-memory graph database written in Rust, with a Cypher-shaped query engine, an HTTP API, and bindings for Node.js, WebAssembly, and Python. It is built for developers who need relationship queries close to their application without adopting a large graph database stack on day one. This release is the beginning of the public journey: source-available core, developer-first adoption, and a path toward a hosted platform for teams that want managed operations later.

Graph databases are overkill for most product work. So I built LoraDB. An embedded, in-memory graph database that runs in the browser at million-node scale, with near-full Cypher support. It’s really, really fast: ~7.4M nodes/sec scans ~3.8M edges/sec traversals ~900K nodes/sec writes Node.js, WASM, Python, Go, Ruby Benchmarks: https://lnkd.in/e_qmfqQQ Curious who else felt this gap.

CloudAEye is pleased to publish the 2026 open source benchmark report for code review. This benchmark is built on 50 real pull requests from five major open source projects, including Cal, Sentry, Keycloak, Discourse, and Grafana. The evaluation spans five programming languages: Python, TypeScript, Java, Go, and Ruby. Each review tool is assessed against human-verified golden comments that capture the issues a thorough reviewer is expected to catch. Every tool is measured on how effectively it identifies these issues and how much irrelevant noise it introduces alongside them. CloudAEye ranks #1 among 21 leading code review agents with an overall F1 score above 65 percent. Refer to the detailed report here: https://lnkd.in/gCs4-KPZ #CodeReview #AI #F1 #benchmark #AIDevTool

How's this for a Monday morning read? A dive into engineering principles behind our architectural decisions for Apache Fluss (Incubating) Rust, Python and C++ clients. Read about our rationale behind adopting single-core multi-language pattern, core implementation in Rust, Apache Arrow format for performance and our aspiration for DataFusion integration, multi-protocol query gateway and more. Anton Borisov Yuxia Luo https://lnkd.in/ey6NmP6Q