500 API کالز میں 10,000 صفحات ماہانہ کو حقیقی تصاویر سے مزین کریں

کنٹینٹ الیسٹریشن کے مسئلے کی ایک ایسی صورت بھی ہے جسے اچھی ذوقی سمجھ سے حل نہیں کیا جا سکتا: آپ ایک تصویر نہیں چن رہے، بلکہ 800 ٹاپک کلسٹرز، 9 لوکیلز اور 14 کلائنٹ سائٹس میں ماہانہ 40,000 امیج سلاٹس بھر رہے ہیں، اور ان میں سے ہر ایک کو لائسنس شدہ، کریڈٹ شدہ، سائز کیا گیا اور اپنے پڑوسی سے مختلف ہونا چاہیے۔ اس حجم پر سوال ”کون سی تصویر؟“ نہیں رہتا بلکہ ”آرکیٹیکچر کیا ہے؟“ بن جاتا ہے۔

یہ مضمون اے پی آئی کا جواب ہے: وہ ریکویسٹ پیٹرن جو کال کاؤنٹ کو دو درجے کم کر دیتا ہے، وہ ورکر جو ریٹ لمٹس کے ساتھ چلتا رہتا ہے، وہ ڈیڈوپلیکیشن جو 10,000 صفحات کی سائٹ کو ایک جیسی سٹاک تصویر کی دیوار بننے سے روکتی ہے — اور ایک صاف گو حصہ اس بارے میں کہ تصاویر آپ کے لیے کیا نہیں کر سکتیں۔

10,000 آرٹیکلز پر اصل رکاوٹ

بڑے پیمانے پر شائع کرنے والی ٹیمیں — پروگرامیٹک ایس ای او اسٹیٹس، مارکیٹ پلیس کیٹیگری صفحات، ایگریگیٹرز، ایفیلیئٹ نیٹ ورکس، کلائنٹس کے پورٹ فولیو کے لیے کنٹینٹ چلانے والی ایجنسیاں، ایک آرٹیکل کو 20 میں تبدیل کرنے والی لوکلائزیشن پائپ لائنز — سب ایک ہی ترتیب میں تین دیواروں سے ٹکراتی ہیں:

1. کال کاؤنٹ۔ ہر امیج سلاٹ کے لیے ایک سرچ کا مطلب ہے 10,000 چار تصاویر والے آرٹیکلز کے لیے 40,000 اے پی آئی کالز۔ ہر پرووائیڈر آپ کو اسی نمبر پر پرائس، تھروٹل اور ریویو کرتا ہے۔
2. تکرار۔ تیسویں صفحے کے آس پاس، وہی تصویر دوبارہ نظر آنا شروع ہو جاتی ہے۔ تین ہزارویں صفحے پر، آپ کی سائٹ کا ایک بصری دستخط بن جاتا ہے: بڑی مقدار میں بنایا گیا۔
3. کوآرڈینیشن۔ ایک کلسٹر میں سو آرٹیکلز کو ایک سیریز جیسا نظر آنا چاہیے، سو غیرمتعلق پنٹرسٹ بورڈز جیسا نہیں — اور اسی آرٹیکل کی اگلی لوکیل کو وہی تصویر دوبارہ استعمال کرنی چاہیے، دوسری زبان میں دوبارہ سرچ نہیں کرنی چاہیے۔

غور کریں کہ اس فہرست میں کیا نہیں ہے: اچھی تصویر ڈھونڈنا۔ ایک سیمینٹک انجن تقریباً 130 ملی سیکنڈ میں قابلِ استعمال امیدواروں کا ایک صفحہ واپس کرتا ہے۔ ریٹریول حل ہو چکا؛ ڈسٹری بیوشن نہیں۔ نیچے دیا گیا سب کچھ ڈسٹری بیوشن کے بارے میں ہے۔

حقیقی تصاویر کیوں، خاص طور پر اس حجم پر

جیسے جیسے حجم بڑھتا ہے، فوٹوگرافی کا کیس جنریشن کے مقابلے میں مضبوط ہوتا جاتا ہے، اور اس کی وجوہات زیادہ تر آپریشنل ہیں، جمالیاتی نہیں۔

ہر کالم دیکھنے کے لیے ٹیبل کو سائیڈ میں سوائپ کریں →

میٹا ڈیٹا والی لائن ہی پائپ لائنز کا فیصلہ کرتی ہے۔ ہر سرچ نتیجہ پہلے سے ہی width، height، blur_hash، color_hex، alt_description اور ایک تیار شدہ attribution.html سٹرنگ لے کر آتا ہے — یہ بالکل وہی پے لوڈ ہے جس کی ٹیمپلیٹنگ انجن کو لے آؤٹ شفٹ سے پاک <img> بنانے کے لیے ضرورت ہوتی ہے، ساتھ ایک پلیس ہولڈر اور ایک کریڈٹ۔ جنریٹڈ تصاویر آپ کو صرف ایک فائل دیتی ہیں اور باقی چھ فیلڈز آپ کے لیے خود بنانے کے لیے چھوڑ دیتی ہیں۔

ایک ریکویسٹ، سو تصاویر

یہی وہ واحد تبدیلی ہے جو ریاضی کی صورت بدل دیتی ہے۔ سرچ اینڈ پوائنٹ per_page کو 100 تک لیتا ہے، اور کرسر پیجینیشن آپ کو اسی رینکڈ ریزلٹ سیٹ میں چلتے رہنے دیتی ہے۔ چنانچہ کام کی اکائی ایک تصویر نہیں، بلکہ ایک پول ہے۔

curl -sG "https://api.pexafy.com/api/v1/search/photos" \
  -H "X-Api-Key: $PEXAFY_API_KEY" \
  --data-urlencode "q=a woman signing paperwork with an insurance agent at a kitchen table in her home" \
  --data-urlencode "per_page=100" \
  --data-urlencode "orientation=landscape" \
  --data-urlencode "score_threshold=0.5" \
  --data-urlencode "fields=photo_id,urls,width,height,blur_hash,alt_description,attribution"

# → { "success": true, "data": [ …100 تصاویر تک… ],
#     "pagination": { "per_page": 100, "has_more": true, "next_cursor": "eyJyc…" },
#     "meta": { "took_ms": 122.33, "request_id": "7ff1fb9b-…" } }

اس میں تین پیرامیٹرز بڑے پیمانے پر خاموشی سے کام کر رہے ہیں:

• fields — ایک اسپارس فیلڈ سیٹ۔ جو سات فیلڈز آپ کا ٹیمپلیٹ رینڈر کرتا ہے صرف انہیں مانگیں تو رسپانس ہر تصویر کی لمبی اے آئی تفصیل بھیجنا بند کر دیتا ہے۔ 40,000 تصاویر پر یہی وہ فرق ہے جو بلڈ کو سٹریم کرنے اور سویپ کرنے کے درمیان ہوتا ہے۔
• score_threshold — 100 نتائج والے صفحے کی دم، بذاتِ خود، سر سے کم متعلقہ ہوتی ہے۔ ایک فرش سیٹ کرنے کا مطلب ہے کہ کمزور کلسٹر 100 اوسط تصاویر کی بجائے 34 تصاویر واپس کرتا ہے، اور آپ کی پائپ لائن ان کے شائع ہونے کی بجائے ان پر ردعمل دے سکتی ہے۔
• next_cursor — جب کسی کلسٹر کو واقعی 300 تصاویر درکار ہوں، تو تین مختلف اوورلیپنگ کویریز چلانے کی بجائے اسی رینکڈ سیٹ کو پیجینیٹ کریں۔

اور یہ رہی ریاضی، ایک ایسی سائٹ کے لیے جو ماہانہ 10,000 صفحات شائع کرتی ہے، ہر ایک میں چار تصاویر کے ساتھ:

ہر کالم دیکھنے کے لیے ٹیبل کو سائیڈ میں سوائپ کریں →

تینوں لائنوں میں وہی 40,000 شائع شدہ تصاویر۔ صرف تبدیل ہونے والی چیز یہ ہے کہ لوپ کہاں لگایا گیا ہے۔

پول اور اسائن: وہ پیٹرن جو اسکیل کرتا ہے

پورا آرکیٹیکچر دو مراحل پر مشتمل ہے جو مختلف تعدد پر چلتے ہیں، درمیان میں ایک ٹیبل کے ساتھ:

                     ┌─────────── ہفتہ وار چلتا ہے، ~500 ریکویسٹس ───────────┐
  topic clusters ──▶ POOL   ہر کلسٹر کے لیے ایک بار سرچ، per_page=100
                     │       └─▶ ہر کلسٹر کے لیے 100 فوٹو رو محفوظ کریں
                     └──────────────────┬───────────────────────────────┘
                                        ▼
                              image_pool ٹیبل
                        (cluster, photo_id, urls, blur_hash,
                         alt, credit, used_by_page, used_at)
                                        │
                     ┌──────────────────┴──── ہر پبلش پر چلتا ہے، 0 ریکویسٹس ───┐
  article ─────────▶ ASSIGN  اس کلسٹر کے لیے بہترین غیر استعمال شدہ
                     │        رو منتخب کریں، استعمال شدہ نشان زد کریں، رینڈر کریں
                     └────────────────────────────────────────────────────────┘

یہ آپ کو جو دیتا ہے، حجم پر اہمیت کی ترتیب میں:

1. پبلشنگ کبھی اے پی آئی پر رکتی نہیں۔ اسائنمنٹ ایک ڈیٹابیس ریڈ ہے۔ آپ کے سی ایم ایس کا سیو ہک، آپ کا سٹیٹک بلڈ اور آپ کا رات 3 بجے کا بلک امپورٹ سب لوکل رفتار پر، آف لائن، اور راستے میں کہیں بھی کسی ریٹ لمٹ کے بغیر چلتے ہیں۔
2. ڈیڈوپلیکیشن مفت اور درست ہے۔ used_by_page IS NULL ہی پورا فیچر ہے۔ دو صفحے ایک ہی تصویر نہیں لے سکتے، کیونکہ اسائنمنٹ ایک ٹرانزیکشن ہے، رینکنگ ہیورسٹک نہیں۔
3. دوبارہ چلانا سستا اور آئیڈم پوٹنٹ ہے۔ کسی کلسٹر کا پول کم ہونے پر یا جب آپ کو تازہ فوٹوگرافی چاہیے ہو (after_date، یا sort_by=newest) اسے تازہ کریں — ایک ریکویسٹ، اور پہلے سے شائع شدہ کچھ بھی نہیں ہلتا۔
4. لوکیلز مفت ملتی ہیں۔ ایک آرٹیکل کے 20 تراجم آپ کے ماڈل میں 20 رینڈرنگز والا ایک ہی صفحہ ہیں؛ وہ اسائن شدہ photo_id شیئر کرتے ہیں اور آپ کبھی دوبارہ سرچ نہیں کرتے۔ جب آپ واقعی کوئی مقامی طور پر لی گئی تصویر کا انداز چاہتے ہوں، تو اس کلسٹر کے لیے پول کویری ہدف زبان میں چلائیں — انجن 100 سے زیادہ زبانوں میں جملہ لے سکتا ہے۔

ورکر، کوڈ میں

تقریباً ساٹھ سطریں۔ پول فلر ہی وہ واحد حصہ ہے جو نیٹ ورک سے بات کرتا ہے، لہٰذا یہی وہ واحد حصہ ہے جسے احتیاط کی ضرورت ہے — کنکرینسی محدود، 429 کا احترام، نتائج ایک ٹرانزیکشن میں لکھے گئے۔

import asyncio, os, time, httpx

SEARCH = "https://api.pexafy.com/api/v1/search/photos"
KEY    = os.environ["PEXAFY_API_KEY"]
FIELDS = "photo_id,urls,width,height,blur_hash,alt_description,attribution"

# Free = 20 req/min۔ ایک نیچے رہیں۔ پیسر GLOBAL ہے: کنکرینسی گیٹ کے
# اندر فی ٹاسک sleep N ورکرز کو N× ریٹ فائر کرنے دے گا۔
PER_MIN = 19
gate    = asyncio.Semaphore(4)         # ان-فلائٹ کنکشنز
_lock   = asyncio.Lock()
_slot   = 0.0                          # مشترکہ ٹائم لائن پر اگلا خالی لمحہ

async def pace():
    """ہر 60/PER_MIN سیکنڈ میں ایک ریکویسٹ سلاٹ دیں، پورے فلیٹ میں۔"""
    global _slot
    async with _lock:
        now  = time.monotonic()
        _slot = max(now, _slot) + 60 / PER_MIN
        wait  = _slot - now
    if wait > 0:
        await asyncio.sleep(wait)

class QuotaExhausted(Exception): ...   # ماہانہ: دوبارہ کوشش سے فائدہ نہیں

async def fill_pool(client, cluster) -> list[dict]:
    """ایک ریکویسٹ → ایک ٹاپک کلسٹر کے لیے 100 کریڈٹ شدہ تصاویر تک۔"""
    for attempt in range(4):
        await pace()
        async with gate:
            r = await client.get(
                SEARCH,
                headers={"X-Api-Key": KEY},
                params={
                    "q": cluster["camera_brief"],   # ایک منظر، کی ورڈ نہیں
                    "per_page": 100,
                    "orientation": "landscape",
                    "score_threshold": 0.5,
                    "fields": FIELDS,
                },
                timeout=15,
            )
        if r.status_code == 429:
            retry_after = r.headers.get("Retry-After")
            if retry_after is None:            # Retry-After نہیں ⇒ ماہانہ کوٹا،
                raise QuotaExhausted(cluster["id"])   # پورا رن روک دیں
            await asyncio.sleep(int(retry_after))   # فی منٹ: یہ صاف ہو جاتی ہے
            continue
        r.raise_for_status()
        return r.json()["data"]
    return []                                  # لاگ کریں؛ پول اپنی پرانی رووز رکھتا ہے

async def refill(clusters):
    async with httpx.AsyncClient(http2=True) as client:
        pools = await asyncio.gather(*(fill_pool(client, c) for c in clusters))
    for cluster, photos in zip(clusters, pools):
        db.upsert_pool(cluster["id"], photos)     # photo_id پر ON CONFLICT DO NOTHING

اس میں دو تفصیلات ہی وہ فرق ہیں جو ایک ورکر کو بغیر نگرانی چلنے دیتی ہیں یا آپ کو جگا دیتی ہیں۔ پیسر گلوبل ہے، فی ٹاسک نہیں: sleep کو کنکرینسی گیٹ کے اندر رکھنا کلاسک غلطی ہے — چار ورکرز جن میں سے ہر ایک اپنی ریکویسٹ کے بعد 3 سیکنڈ رکتا ہے، ہر 3 سیکنڈ میں چار ریکویسٹس پیدا کرتے ہیں، یعنی فی منٹ تقریباً 75، اور فری پلان فوراً 429 واپس کرنا شروع کر دیتا ہے۔ اور دونوں 429 ایک جیسے جانور نہیں ہیں: فی منٹ والا Retry-After لے کر آتا ہے اور خود ہی صاف ہو جاتا ہے، ماہانہ کوٹے والا اسے نہیں لاتا اور کبھی نہیں لائے گا — اس پر دوبارہ کوشش کرنا دیوار کے خلاف لوپ ہے۔

اسائنمنٹ، وہ حصہ جو ہر پبلش پر چلتا ہے، کبھی نیٹ ورک کو نہیں چھوتا:

# یکتائیت اسکیما نافذ کرتا ہے، محتاط کویری نہیں۔
# ایک تصویر کئی کلسٹر پولز میں موجود ہو سکتی ہے؛ یہ صرف ایک بار PUBLISHED ہو سکتی ہے۔
# CREATE UNIQUE INDEX one_use_per_photo ON image_pool (photo_id)
#        WHERE used_by_page IS NOT NULL;

def assign_hero(page_id: str, cluster_id: str) -> dict | None:
    for _ in range(5):                # ہارا ہوا ریس صرف اگلی تصویر لیتا ہے
        try:
            return db.query_one("""
                UPDATE image_pool p SET used_by_page = %s, used_at = NOW()
                WHERE p.id = (
                    SELECT c.id FROM image_pool c
                    WHERE c.cluster_id = %s AND c.used_by_page IS NULL
                      AND NOT EXISTS (              -- کیا کسی اور کلسٹر نے استعمال کیا؟
                          SELECT 1 FROM image_pool u
                          WHERE u.photo_id = c.photo_id
                            AND u.used_by_page IS NOT NULL
                      )
                    ORDER BY c.rank ASC
                    LIMIT 1 FOR UPDATE SKIP LOCKED  -- متوازی ورکرز کے ساتھ محفوظ
                )
                RETURNING photo_id, urls, width, height, blur_hash, alt, credit
            """, [page_id, cluster_id])
        except UniqueViolation:      # دو کلسٹرز نے اسی ملی سیکنڈ میں دعویٰ کر دیا
            continue
    return None                     # پول خالی → بریف کو وسیع کریں، دوبارہ بھریں

# رینڈرنگ: ہر خاصیت رو سے آتی ہے — کوئی لے آؤٹ شفٹ نہیں، کوئی اندازہ نہیں۔
# <img src="{urls[regular]}" width="{width}" height="{height}"
#      alt="{alt}" loading="lazy" style="background:{blur_placeholder}">
# <figcaption>{credit}</figcaption>

دو ناکامی کے انداز، دو میکانزم، اور دونوں کی ضرورت ہے۔ FOR UPDATE SKIP LOCKED ایک کلسٹر کے اندر کنکرینسی کو ہینڈل کرتا ہے: صفحات کو متوازی طور پر جنریٹ کریں — اور اس حجم پر آپ ایسا ہی کریں گے — اور دو ورکرز اسی ملی سیکنڈ میں سب سے اوپر رینکڈ تصویر کے لیے پہنچتے ہیں۔

جزوی یکتا انڈیکس اس چیز کو ہینڈل کرتا ہے جسے سب بھول جاتے ہیں: وہی تصویر جائز طور پر کئی کلسٹرز کے پولز میں ظاہر ہو سکتی ہے، کیونکہ ملحقہ کلسٹرز (”کرایہ داروں کے لیے ہوم انشورنس“، ”...مالکان کے لیے“) اوورلیپنگ نتائج واپس کرتے ہیں۔ فی کلسٹر used_by_page IS NULL چیک اس سے بے خبر ہے — ہر کلسٹر سمجھتا ہے کہ تصویر خالی ہے۔ NOT EXISTS کویری کو ایماندار رکھتا ہے، اور انڈیکس کنکرینسی کے تحت اسے غلط ہونے سے ناممکن بنا دیتا ہے: ریس ہارنے والا وائلیشن پاتا ہے، دوبارہ کوشش کرتا ہے، اور اگلی تصویر لیتا ہے۔ اس کے بغیر، ”کوئی دو صفحے ہیرو شیئر نہیں کرتے“ ایک دعویٰ ہے، ضمانت نہیں۔

جب کوئی پول بلڈ کے دوران خالی ہو جائے، تو سب سے بہتر رویہ رکھنے والا فال بیک دہرانے کی بجائے وسیع کرنا ہے: کیمرہ بریف کی آخری شق ہٹائیں، پول کویری ایک بار دوبارہ چلائیں، اور اسی وقت سب سے پرانی تفویض شدہ تصویر دوبارہ استعمال کریں — اس سخت اصول کے ساتھ کہ وہ کبھی اسی کلسٹر کے کسی صفحے پر نہ اترے۔

ایک کلسٹر، ایک پول: ایک حقیقی کویری

ایک موازنہ اسٹیٹ لیں: ہوم انشورنس، بیس صفحات — ”کرایہ داروں کے لیے ہوم انشورنس“، ”...مالکان کے لیے“، ”پالیسی اصل میں کیا کور کرتی ہے“، بارہ شہری صفحات، تین کلیم گائیڈز۔ اس کلسٹر کے لیے ایک کیمرہ بریف، ایک ریکویسٹ، اور یہ پول کا سر ہے، جو 122 ms میں واپس آیا:

GET /search/photos — ”ایک عورت اپنے گھر کی کچن ٹیبل پر انشورنس ایجنٹ کے ساتھ کاغذی کارروائی پر دستخط کر رہی ہے“ · 122 ms

اوپر نتیجہ · 0.85Pexels Pexels Pexels Pexels Pexels Pexels

بریفس کوڈ سے زیادہ اہمیت رکھتے ہیں۔ حقیقی اسٹیٹ کے کلسٹرز کے ساتھ رابطے میں دو اصول قائم رہتے ہیں: بریف کلسٹر کے لیے لکھیں، صفحے کے لیے نہیں (پروگرامیٹک سیٹس میں پیج ٹائٹلز تقریباً ایک جیسے ہوتے ہیں، لہٰذا فی صفحہ بریفس تقریباً ایک جیسی تصاویر واپس کرتے ہیں)، اور ٹاپک کی بجائے وہ منظر بیان کریں جو کیمرہ لے سکتا تھا — home insurance صرف دستاویز کے کلوز اپس اور کچھ نہیں واپس کرتا۔ ہم نے وہ کاپی پیسٹ ہو سکنے والا پرامپٹ ہر پوسٹ کو الیسٹریٹ کرنے والے مضمون میں شائع کیا ہے جو یہ بریفس بناتا ہے۔

200 صفحات کی سیریز کو بصری طور پر مربوط رکھنا

تکرار کی الٹی ناکامی عدم مطابقت ہے: ایک کلسٹر میں بیس صفحات، ہر ایک میں تکنیکی طور پر درست تصویر، بیس مختلف بصری اندازوں میں۔ اس کا حل ایک اینڈ پوائنٹ ہے — GET /photos/{id}/similar — جو اس تصویر پر ایک بار چلایا جاتا ہے جسے آپ نے پیلر پیج کے لیے منظور کیا:

GET /photos/019e143f…/similar — منظور شدہ ہیرو جیسی مزید تصاویر · 48 ms

0.97Pexels Pexels Pexels

دو مزید لیورز جب برانڈ کی مطابقت ضروری ہو تو پول کویری میں جوڑنے کے قابل ہیں: color_hex بمعہ color_tolerance پوری اسٹیٹ کو ایک پیلٹ کے اندر رکھتا ہے، اور photographer ایک کلسٹر کو ایک ہی فوٹوگرافر کے کام سے جوڑتا ہے۔ دونوں عام کویری پیرامیٹرز ہیں — سرچ فلٹرز پر کوئی پلان گیٹنگ نہیں۔

ریٹ لمٹس، کوٹے اور اصل لاگت

پلان کا انتخاب برسٹ کی بنیاد پر کریں، حجم کی بنیاد پر نہیں۔ ایک بار پول کرنے کے بعد، ماہانہ کوٹا تقریباً سب کے لیے رکاوٹ رہنا بند ہو جاتا ہے؛ آپ کے پلان کا فیصلہ یہ کرتا ہے کہ مکمل ری فریش کتنی تیزی سے مکمل ہونا ضروری ہے۔

ہر کالم دیکھنے کے لیے ٹیبل کو سائیڈ میں سوائپ کریں →

پہلے کالم کو کلسٹرز کے طور پر پڑھیں: ایک پولنگ ریکویسٹ ایک کلسٹر بھرتی ہے، لہٰذا ماہانہ کوٹا اتنے کلسٹرز کی تعداد ہے جتنے آپ ری فریش کر سکتے ہیں، اور آخری کالم یہ ہے کہ 1,000 کلسٹرز کی اسٹیٹ پر ایک مکمل پاس اس پلان کی ریٹ لمٹ پر کتنا وقت لیتا ہے۔ دونوں پرائسنگ کیٹلاگ کی لائیو ویلیوز ہیں — پرائسنگ صفحہ وہی ریٹ لمٹس فی گھنٹہ بتاتا ہے، فی منٹ نہیں۔

چنانچہ پول شدہ پیٹرن پر ماہانہ 10,000 صفحات کی ایک اسٹیٹ ~500 ریکویسٹس خرچ کرتی ہے اور کچھ نہیں ادا کرتی۔ جو چیز ٹیموں کو ٹیبل میں اوپر دھکیلتی ہے وہ شاذ و نادر ہی حجم ہے — یہ تین چیزوں میں سے ایک ہوتی ہے: کسی موجودہ اسٹیٹ کی ایک رات میں مکمل دوبارہ الیسٹریشن، فی کلائنٹ کی آئسولیشن (کوئی ایجنسی چاہتی ہے کہ فی کلائنٹ ایک کی ہو تاکہ استعمال شیئرڈ سیکرٹ کی گیمکس کے بغیر قابلِ نشاندہی ہو)، یا منٹوں میں ناپا جانے والا بلڈ ونڈو، گھنٹوں میں نہیں۔

دو آپریشنل تفصیلات جو ڈیبگنگ کی ایک رات بچاتی ہیں۔ ہر رسپانس X-RateLimit-Limit اور X-RateLimit-Remaining لے کر آتا ہے، تاکہ ورکر اندازہ لگانے کی بجائے خود کو رفتار دے سکے۔ اور جو 429 واقعی فی منٹ ریٹ لمٹ ہو وہ Retry-After لے کر آتا ہے، جبکہ ماہانہ کوٹے کی روک جان بوجھ کر ایسا نہیں کرتی — دوبارہ کوشش اسے صاف نہیں کرے گی، اور جو ورکر ان دونوں میں فرق کرتا ہے وہ اس اینڈ پوائنٹ کو مارنا بند کر دیتا ہے جس کے پاس دینے کو کچھ باقی نہیں۔

جب ایجنٹ ہی پبلشنگ کرتا ہے

اگر آپ کا کنٹینٹ ایک ایجنٹ کے ذریعے تیار کیا جاتا ہے — اور اس حجم پر یہ تیزی سے ایسا ہی ہو رہا ہے — تو پولنگ لیئر غائب نہیں ہوتی، بس منتقل ہو جاتی ہے۔ ایجنٹ کو سرچ ٹولز دیں اور یہ پول کو اسی وقت بھرتا ہے جب اس کے پاس کلسٹر بریف اب بھی کانٹیکسٹ میں موجود ہو، اس کے لیے Model Context Protocol سرور استعمال کرتے ہوئے mcp.pexafy.com/mcp پر: تین ٹولز، search_photos (ایک جملہ)، search_photos_by_image (ایک ریفرنس تصویر، اختیاری طور پر جملے کے ساتھ) اور get_similar_photos (اوپر والا سیریز کی مطابقت والا ٹول)۔

# Claude Code / CI رنر
claude mcp add --transport http pexafy https://mcp.pexafy.com/mcp \
  --header "Authorization: Bearer $PEXAFY_API_KEY"

# یا .mcp.json کمٹ کریں تاکہ فلیٹ کا ہر ورکر اسے وراثت میں پائے
{
  "mcpServers": {
    "pexafy": {
      "type": "http",
      "url": "https://mcp.pexafy.com/mcp",
      "headers": { "Authorization": "Bearer YOUR_API_KEY" }
    }
  }
}

جو ہدایت بڑے پیمانے پر کام کرتی ہے وہ فی آرٹیکل نہیں بلکہ ایک بیچ ہدایت ہے — اور یہ اوپر دیے گئے دونوں مراحل پر یکسر مطابق بیٹھتی ہے:

You  کنٹینٹ کیلنڈر سے یہ 12 ٹاپک کلسٹرز ہیں۔ ہر ایک کے لیے،
     ایک کیمرہ بریف لکھیں، 100 لینڈ اسکیپ تصاویر نکالیں، اور
     پول کو Postgres میں لکھیں۔ کسی بھی کلسٹر کو نشان زد کریں جو 0.5 سے اوپر
     40 سے کم نتائج واپس کرے — انہیں بریفس دوبارہ لکھنے کی ضرورت ہے۔

Agent  → search_photos(q="a woman signing paperwork with an insurance
           agent at a kitchen table in her home", orientation="landscape")
      ← 100 تصاویر · 122 ms · 87 تھریشولڈ سے اوپر
      … مزید 11 کلسٹرز …

      ✓ 11 پولز لکھے گئے (1,043 تصاویر، سب کریڈٹ شدہ)
      ⚠ ”index fund rebalancing“ → 12 نتائج۔ بریف تجریدی ہے؛
        تجویز: ”ایک شخص کچن ٹیبل پر لیپ ٹاپ پر اعداد چیک کر رہا ہے،
        ساتھ ایک نوٹ بک اور کافی ہے“

آخری لائن ہی وہ وجہ ہے کہ ایجنٹ کو اس لوپ میں رکھا جائے، سکرپٹ کی بجائے: پروگرامیٹک الیسٹریشن کی ناکامی کا انداز خراب بریف ہے، اور خراب بریف بالکل وہی چیز ہے جسے ایک لینگویج ماڈل محسوس کر کے دوبارہ لکھ سکتا ہے۔ سکرپٹس اسائنمنٹ کے انچارج رہتے ہیں، جہاں ڈیٹرمنزم اہم ہے اور تخلیقیت نہیں۔

جو تصاویر ٹھیک نہیں کر سکتیں

ایک صاف گو حصہ، کیونکہ جس ناکامی کو یہ بیان کرتا ہے وہ مہنگی ہے۔ حقیقی، کریڈٹ شدہ فوٹوگرافی کسی صفحے کو بہتر بناتی ہے۔ یہ کمزور کنٹینٹ کو اچھے کنٹینٹ میں تبدیل نہیں کرتی، اور کوئی امیج پائپ لائن اسے نہیں بدلتی کہ سرچ انجن بڑے پیمانے پر بنائے گئے صفحات کے ساتھ کیسا سلوک کرتے ہیں جو مدد کرنے کی بجائے رینک کرنے کے لیے موجود ہوں۔ گوگل کی اسپیم پالیسیز اسے براہ راست نام دیتی ہیں: اسکیلڈ کنٹینٹ ابیوز اس صورت کو کور کرتا ہے جہاں بہت سے صفحات بنائے جائیں جن میں معمولی قدر ہو خواہ آٹومیشن شامل ہو یا نہیں، اور ان صفحات پر الیسٹریشنز اس فیصلے سے غیرمتعلق ہیں۔2

چنانچہ کارآمد فریمنگ محدود اور سچی ہے: فوٹوگرافی ایک کوالٹی سگنل ہے جسے آپ کنٹرول کرتے ہیں ان صفحات پر جو پہلے سے موجود ہونے کے لائق ہیں۔ جہاں یہ ثابت شدہ طور پر فائدہ دیتی ہے:

• پروونینس جسے قاری تصدیق کر سکے۔ فوٹوگرافر کے نام اور سورس یو آر ایل کے ساتھ کریڈٹ لائن ایک دعویٰ ہے جسے چیک کیا جا سکتا ہے — بغیر کریڈٹ والی تصویر، بغیر کریڈٹ والے مصنف کے صفحے پر، کی الٹ۔
• رسائی پذیری اور Core Web Vitals۔ رسپانس سے width/height لے آؤٹ شفٹ ختم کرتے ہیں، blur_hash ایک حقیقی پلیس ہولڈر دیتا ہے، اور alt_description آلٹ ٹیکسٹ کا ایک ڈرافٹ ہے جسے آپ کا ٹیمپلیٹ بہتر بنا سکتا ہے، خود سے بنانے کی بجائے۔ اسے 40,000 سلاٹس سے ضرب دیں تو یہی سائٹ کی پوری امیج کوالٹی کی کہانی بنتی ہے۔
• بڑے پیمانے پر بنایا ہوا نظر نہ آنا۔ ڈیڈوپلیکیشن اور سیریز کی مطابقت ہی وہ چیزیں ہیں جو کسی اسٹیٹ کو ایک بصری دستخط رکھنے سے روکتی ہیں۔ یہ ایک حقیقی تاثر کی لاگت ہے جس کے حقیقی نتائج ہوتے ہیں، اور یہ مکمل طور پر آپ کے کنٹرول میں ہے۔

اور لائسنس اب بھی تصویر پر لاگو ہوتا ہے۔ Pexafy کی اے پی آئی شرائط کے تحت اٹریبیوشن ضروری نہیں — ہر نتیجہ attribution.html اور attribution.plain رینڈر کرنے کے لیے تیار لے کر آتا ہے — لیکن اصل لائبریری کا منسلک لائسنس آپ کے اس تصویر کے استعمال پر لاگو ہوتا ہے، اور ماہانہ 40,000 تصاویر پر، کریڈٹ خودکار طور پر رینڈر کرنا بعد میں آڈٹ کرنے سے سستا ہے۔

پیر کے دن کہاں سے شروع کریں

1. اپنے بیک لاگ کو کلسٹرز میں گروپ کریں 15–30 صفحات کے، جو معقول طور پر ایک ہی فوٹو شوٹ شیئر کر سکیں۔ یہ واحد حقیقی طور پر دستی مرحلہ ہے، اور یہ ایک اسپریڈشیٹ ہے، پروجیکٹ نہیں۔
2. ہر کلسٹر کے لیے ایک کیمرہ بریف لکھیں — ایک منظر، 12 سے 25 الفاظ۔ انہیں ایک ماڈل سے جنریٹ کریں، پھر پڑھیں؛ وہ بریفس جو منظر کی بجائے ٹاپک کا نام لیتے ہیں ایک نظر میں نمایاں ہوتے ہیں۔
3. ایک پول بھریں ایک واحد per_page=100 ریکویسٹ سے اور اس کے سر کو دیکھیں۔ اگر اوپر کی دس قابلِ استعمال نہیں، تو بریف غلط ہے — انجن نہیں۔
4. used_by_page کالم شامل کریں کچھ بھی شائع کرنے سے پہلے۔ ابھی یہ پانچ منٹ کا کام ہے اور بعد میں 3,000 لائیو صفحات پر مائیگریشن بن جاتا ہے۔
5. پورا کام فری پلان پر چلائیں جب تک کہ کوئی بلڈ ونڈو آپ کو اوپر جانے پر مجبور نہ کرے۔ ماہانہ 500 ریکویسٹس پر، اس میں کچھ وقت لگے گا۔

حوالہ جات اور فٹ نوٹس