PHP задачи с собеседований

❓ Что такое Lazy Collections в Laravel?

Обычная Collection загружает всё в память сразу. При работе с большими объёмами данных — это проблема.

// ❌ Загрузит ВСЕ записи в память
$users = User::all()->filter(...)->map(...);

// ✅ Lazy Collection — обрабатывает по одной записи через генератор
User::cursor()->filter(function (User $user) {
return $user->is_active;
})->each(function (User $user) {
ProcessUser::dispatch($user);
});

cursor() использует PDO fetchRow под капотом — в памяти одновременно одна запись.

Lazy Collection из файла:

// Обработка огромного CSV без OutOfMemoryError
$collection = LazyCollection::make(function () {
$handle = fopen('huge_file.csv', 'r');
while ($row = fgetcsv($handle)) {
yield $row;
}
});

$collection->skip(1)->chunk(100)->each(function ($rows) {
ImportBatch::dispatch($rows->toArray());
});

Когда использовать

— 10k+ записей в обработке → cursor() + LazyCollection
— Файлы, стримы, внешние API с пагинацией → LazyCollection с генератором

Важно: методы типа count() и last() материализуют коллекцию. Их лучше избегать в lazy-контексте.

💬 Обратная связь

Какие темы освещать чаще?

🔥 — PHP Core
👍🏼 — Laravel / Symfony
❤️ — Паттерны и дизайн
😁 — Предложу в комменты

❓ Что такое событийно-ориентированная архитектура?

Event-driven architecture — это когда компоненты общаются через события, не зная друг о друге напрямую.

// Событие:
class UserRegistered {
public function __construct(public readonly User $user) {}
}

// Listener:
class SendWelcomeEmail {
public function handle(UserRegistered $event): void {
$this->mailer->send($event->user->email, 'Welcome!');
}
}

// Диспетчер:
$dispatcher->dispatch(new UserRegistered($user));

Зачем

✔️ Слабая связанность (UserService не знает о SendWelcomeEmail)
✔️ Легко добавить новый listener без изменения существующего кода (Open/Closed)
✔️ Можно делать асинхронные listeners (через очередь)

В Laravel: Event / Listener, EventServiceProvider.
В Symfony: EventDispatcher, декларация через атрибуты.

Подводный камень: сложно трейсить цепочку — одно событие вызывает другое.

💬 Обратная связь

Текущий уровень сложности задачек?

🔥 — Слишком просто, хочу сложнее
👍🏼 — В самый раз
❤️ — Иногда сложновато
😁 — Часто не понимаю

❓ Чем отличается Optimistic Lock от Pessimistic Lock?

Pessimistic Lock — блокируем строку в БД на время транзакции. Никто другой не может её изменить до снятия блокировки.

SELECT * FROM orders WHERE id = 1 FOR UPDATE;

Применять когда: высокая вероятность конфликта, критичные финансовые операции, короткие транзакции.
Минус: снижает throughput, риск дедлоков при блокировке нескольких строк в разном порядке.

Optimistic Lock — блокировки нет. У записи есть поле version. При обновлении проверяем, что версия не изменилась:

UPDATE orders SET status = 'paid', version = 6
WHERE id = 1 AND version = 5;

Если affected_rows = 0 — кто-то успел раньше, делаем retry или возвращаем ошибку.

Применять когда: конфликты редки, операции долгие (нельзя держать блокировку), высокий параллелизм.
Минус: нужен retry-механизм, сложнее реализовать корректно.