Розробка платформи для оренди житла: пошук, бронювання, платежі

Розробка rental-платформи — не просто верстка лістингів та форма бронювання. Ключова складність — логіка доступності, платежів і синхронізації. Якщо в момент підтвердження броні на один і той самий об'єкт приходять два запити, без правильного блокування обидва пройдуть — і хазяїн отримає подвійну переплату, а гість — відмову. Ми проєктуємо транзакційні системи, де race condition виключені на рівні СУБД. Наприклад, у проєкті для мережі апартаментів у Мінську ми обробляємо 500+ бронювань на добу без жодного конфлікту за 2 роки експлуатації. Рішення — на Laravel + PostgreSQL з SELECT FOR UPDATE та скінченним автоматом статусів. Нижче — конкретний устрій ключових модулів.

Окрім коректності даних, гостро стоїть питання продуктивності. Core Web Vitals — LCP, CLS, INP — безпосередньо впливають на конверсію. Ми досягаємо LCP < 1.5 за допомогою серверного рендерингу (Next.js), оптимізації зображень та CDN. Для складних карт з кластеризацією використовуємо vector tiles та lazy loading.

Чому модель доступності — ядро будь-якої rental-платформи?

Жоден available: boolean на об'єкті не працює. Потрібна окрема таблиця періодів з типами блокувань — booked, owner_blocked, maintenance, external_ical. Тільки так можна коректно перевіряти доступність на перетин дат. Різниця між PostGIS та MySQL Spatial — у 3 рази вища продуктивність на радіусі 50 км завдяки GiST-індексам.

CREATE TABLE availability_blocks ( id BIGSERIAL PRIMARY KEY, listing_id BIGINT NOT NULL REFERENCES listings(id), start_date DATE NOT NULL, end_date DATE NOT NULL, block_type VARCHAR(20) NOT NULL, booking_id BIGINT REFERENCES bookings(id), CHECK (end_date > start_date) ); CREATE INDEX idx_availability_listing_dates ON availability_blocks (listing_id, start_date, end_date); 

Запит перевірки доступності під блокуванням SELECT FOR UPDATE — обов'язкова умова, інакше при одночасних запитах на один об'єкт виникає race condition.

Пошук з геофільтрацією: PostGIS vs MySQL Spatial

Для geo-пошуку PostGIS в 3 рази швидше MySQL Spatial: підтримка SRID 4326, функції ST_DWithin та ST_Distance з географічними типами, індекси GiST. На фронті використовуємо Mapbox GL JS — векторні тайли дають кращий UX.

SELECT l.id, l.title, l.price_per_night, ST_Distance(l.location, ST_MakePoint($1, $2)::geography) AS distance_meters FROM listings l WHERE ST_DWithin( l.location, ST_MakePoint($1, $2)::geography, $3 ) AND l.guests_max >= $4 AND l.bedrooms >= $5 AND NOT EXISTS ( SELECT 1 FROM availability_blocks ab WHERE ab.listing_id = l.id AND ab.block_type IN ('booked', 'owner_blocked') AND ab.start_date < $7 AND ab.end_date > $6 ) ORDER BY distance_meters LIMIT 50; 

Система бронювання: скінченний автомат на Laravel

class Booking extends Model { public function confirm(): void { if ($this->status !== BookingStatus::PendingPayment) { throw new InvalidBookingTransitionException( "Cannot confirm booking in status: {$this->status->value}" ); } DB::transaction(function () { $this->update(['status' => BookingStatus::Confirmed]); AvailabilityBlock::create([ 'listing_id' => $this->listing_id, 'start_date' => $this->check_in, 'end_date' => $this->check_out, 'block_type' => 'booked', 'booking_id' => $this->id, ]); event(new BookingConfirmed($this)); }); } } 

Платежі та утримання коштів: Stripe Connect

Ключова особливість rental: гроші утримуються при бронюванні та зараховуються хазяїну після check-in (або checkout). Stripe Connect з capture_method: manual дозволяє захопити кошти пізніше. Періодичні задачі (scheduled jobs) обробляють виплати та повернення. Помилка в логіці виплат може коштувати до 15% обороту через комісії та повернення — тому ми тестуємо кожен сценарій вручну. Економія на комісіях при власній платформі може досягати 10–15% від обороту — при 1000 бронюваннях на місяць із середнім чеком $200 це $24 000–36 000 на рік.

Як уникнути конфліктів при синхронізації з Airbnb та Booking?

Підключаємо iCal (RFC 5545): хазяїн вказує URL календаря, система імпортує зовнішні блокування. Експорт — навпаки. Laravel Scheduler запускає синхронізацію кожні 15–30 хвилин. Тоді об'єкт не буде заброньований одночасно на різних платформах.

Система відгуків із двосторонньою анонімністю

Відгуки публікуються лише після того, як обидві сторони залишили відгук, або після закінчення 14 днів з checkout. Це виключає тиск і підвищує довіру. Реалізація з published_at та periodic job.

Що таке Core Web Vitals і чому вони важливі для rental-платформ?

Google ранжує сайти за метриками LCP, CLS, INP. Для rental-платформи критичні: швидкість завантаження сторінки лістингу (LCP), стабільність макету при підвантаженні зображень (CLS) та чуйність фільтрів (INP). Ми досягаємо LCP < 1.5 за допомогою серверного рендерингу (Next.js), оптимізації зображень та CDN. Для складних карт з кластеризацією використовуємо vector tiles та lazy loading.

Як ми реалізуємо платіжну систему: покроково

1. Проєктування схеми платежів: вибір Stripe Connect, налаштування capture_method: manual
2. Реалізація ендпоінтів для створення PaymentIntent та підтвердження
3. Обробка вебхуків (payment_intent.succeeded, charge.disputed)
4. Scheduled jobs для виплат хазяям (із затримкою після check-in)
5. Тестування всіх кейсів: успішна оплата, скасування, повернення, спір

Що входить в роботу

• Проєктування архітектури БД, API, схеми платежів
• Розробка лістингів, пошуку, бронювання, чатів
• Інтеграція Stripe Connect, iCal, email-повідомлень
• Розгортання на інфраструктурі замовника (VPS, Docker)
• Документація, навчання адміністраторів, 6 місяців гарантії

Строки розробки

Базова версія (пошук, бронювання, Stripe, кабінети): 10–12 тижнів. З iCal, відгуками, картою з кластеризацією: 14–18 тижнів. Повний функціонал (модерація, верифікація, dispute resolution, аналітика): 20–24 тижні. Тестування граничних випадків з виплатами — найтриваліший етап, кожен баг або втрата грошей, або юридичний ризик.

Замовте консультацію — проаналізуємо ваш проєкт і запропонуємо архітектуру. Отримайте оцінку протягом дня. Зв'яжіться з нами, щоб обговорити деталі.