Asynchronous programming in Python: asyncio, FastAPI and SQLAlchemy

Course overview

Description generated based on course syllabus and open data.

The materials cover asynchronous programming in Python: asyncio, the Event Loop, non-blocking I/O, building web services with FastAPI, and database access via SQLAlchemy (async drivers). Both synchronous and asynchronous approaches are discussed, including synchronization primitives, race conditions, and coordination with multiprocessing for CPU-intensive tasks.

Lecturer: Serhii Ruskikh — Python and asynchronous web services

Lead Python Software Engineer at SoftServe. 13+ years in software development, 10+ years using Python for web services and data processing. Experience: E-commerce, warehouse automation, contact center software, media adtech. Co-organizer of LvivPy and Ukraine Python Community; PyConUA and LvivPy speaker.

Who it suits (asynchronous programming, Python, asyncio) and who it does not

Suitable

• Python developers tackling I/O-heavy workloads: HTTP, queues, databases, caches.
• Those building web services with FastAPI who need efficient concurrency.
• Engineers working on integrations and data extraction (ETL) requiring non-blocking processing.

Not suitable

• Primarily CPU-bound scenarios better served by multiprocessing or C extensions.
• Basic scripts without network calls or database interactions.

Problem → outcome (asynchronous programming, FastAPI, SQLAlchemy)

• Problem: Blocking calls in synchronous DB drivers. Outcome: Async SQLAlchemy/drivers with non-blocking I/O.
• Problem: Low throughput in HTTP services. Outcome: FastAPI + asyncio, coroutines, connection pools, timeouts, retries.
• Problem: Race conditions and improper synchronization. Outcome: asyncio primitives (Lock, Semaphore, Queue), controlled access, idempotency patterns.
• Problem: Mixing CPU-bound and I/O-bound loads. Outcome: Separation of concerns: asyncio for I/O, multiprocessing/executors for CPU tasks.

Comparison with alternatives: synchronous model, multithreading, multiprocessing vs asyncio

• Sync stack (Flask + sync drivers): easy to start, but blocks on I/O, limiting scalability.
• Threads (threading): convenient for mixed workloads, but overhead, GIL contention, complex synchronization.
• Multiprocessing: strong for CPU-bound tasks, but heavier IPC, data serialization, higher context costs.
• Asyncio + FastAPI + async SQLAlchemy: non-blocking operations and high concurrency for I/O-bound; requires careful library choices and design.

Outcomes covered (asyncio, Event Loop, web services, databases)

• Understanding of the Event Loop, tasks, coroutines, timeouts, cancellation, and exception handling.
• Use of synchronization primitives, avoidance of race conditions, and idempotency patterns.
• REST API design with FastAPI: middleware, validation, logging, and testing.
• Database integration with async SQLAlchemy: sessions, transactions, pools, indexing, query profiling.
• Combining asyncio with multiprocessing/executors for different workload classes.
• Practical case: a service suite to ingest and persist CVE data and expose it via API.