CASE STUDY · 24/7 AUTOMATION

Steam Rental Ops: a 24/7 marketplace workflow

A production automation platform that receives and deduplicates marketplace orders, delivers access, monitors a live Dota 2 session, rotates credentials safely, and returns inventory to sale.

Build something similar ↗View architecture

Steam Rental Ops administration dashboard — Selected project material · anonymized where required

24/7automated rental flow

60 smonitor cycle

30 slive match recheck

2 × 10/10client reviews

THE CHALLENGE

What had to remain reliable.

FunPay, Steam, Dota GC, proxies, and Telegram can become slow or unavailable independently. An order must never be issued twice, a stale checker must not be treated as proof that a match ended, password rotation must stay on the assigned proxy, and partial failure must not leave a listing hidden.

THE SOLUTION

How the system was designed.

Orders and reviews are idempotent, durable state lives in SQLite, Steam checkers are isolated processes with database heartbeats, stale match data triggers a fresh check, and rental completion has both primary and recovery paths. Proxy credentials are normalized and masked throughout the system.

DELIVERED

The working scope.

A modular application lifecycle with adapters, services, repositories, and independently supervised processes.
Automated order routing, availability checks, listing suspension, access delivery, confirmation, and reliable extensions.
Safe rental expiry that checks live Dota 2 match state every 30 seconds before changing credentials.
Per-account HTTP/SOCKS proxy handling with remote DNS, credential masking, and consistent routing across Steam operations.
A Telegram operations console for accounts, rentals, manual actions, proxies, checkers, statistics, alerts, and access control.

ARCHITECTURE

The main system boundaries and data flow.

[ FunPay orders + reviews ]
              | idempotent event processing
              v
      [ Rental application services ] <----> [ SQLite state ]
          |              |                         |
          v              v                         v
 [ listing control ] [ credential flow ] [ scheduler / recovery ]
          |              |                         |
          +--------------+-------------------------+
                         v
   [ isolated Steam checkers + proxy + heartbeat + watchdog ]
                         |
                         v
                 [ Dota 2 live match state ]

                  [ Telegram operations console ]

OUTCOMES

What the architecture enables.

An end-to-end rental lifecycle without routine operator work

Protection against duplicate marketplace events

No forced credential rotation during a live match

Operational visibility and recovery controls in Telegram

STACKPythonasyncioFunPay APISteamDota 2 GCTelegram BotSQLitePySockssystemd

YOUR PROJECT CAN START WITH A SHORT TECHNICAL REVIEW

Show me the workflow, integration points, and current bottleneck.

Discuss the project ↗