What makes a well designed Airflow DAG, and what mistakes do you look for in review?

A good DAG has small idempotent tasks with clear dependencies, derives its time window from the data interval rather than the wall clock, and keeps heavy logic out of the DAG file since that file is parsed constantly. Avoid passing large data through XCom, avoid long blocking sensors that occupy worker slots, and set sensible retries, timeouts, and alerting on the tasks that matter.

The two things I care about most are task granularity and idempotency. Tasks should be small enough that a failure is cheap to retry and specific enough that the failure tells you what broke, and every one of them should be safe to rerun. Then the time window has to come from the data interval Airflow passes in, never from datetime.now inside the task, otherwise a rerun of last Tuesday processes today's data and you get a subtle wrong answer instead of an error. In review, the thing I flag most often is expensive code at the top level of the DAG file. That file gets parsed on a short interval, so an API call or a database query outside the task function runs constantly and degrades the whole scheduler; I have seen that alone add minutes to scheduling latency across an entire deployment. I also check XCom usage, since it is a metadata table and not a data transport, so pass an S3 path rather than a dataframe.