Ivan Katkov
Selected work/Case 10

Integration platform · Backend leadership · May 2019 — Aug 2019

Connecting university support across VK, Telegram and OTRS

I coordinated backend delivery and built asynchronous Python services connecting messaging channels, OTRS and PostgreSQL workflows.

5backend engineersCoordinated delivery
3core integrationsVK, Telegram and OTRS
Asyncservice modelAiohttp and asyncpg
CASE / 10 SYSTEM ONLINE
Innopolis UniversityA multi-channel support system led by a five-person backend team

IMAGE PLACEHOLDER · Replace through public/images/cases and the case-study data file.

01 · Executive summary

The shortest honest version.

Situation

University support requests arrived through disconnected channels and needed a consistent route into the ticketing system.

Intervention

I coordinated a five-person team and designed asynchronous service and integration boundaries around VK, Telegram, OTRS and PostgreSQL.

Result

The project established one backend workflow for multi-channel request intake, ticket orchestration and documented delivery.

02 · Context

Why the engineering work mattered.

Students and staff used different communication channels while support operations depended on OTRS.

The system needed to translate messages and status changes without coupling every channel directly to ticket logic.

03 · System design

A clear path from signal to production.

01VK / Telegram

Independent channel adapters.

02Message model

Normalized internal request format.

03Workflow service

Routing and ticket orchestration.

04OTRS + Postgres

Ticketing integration and persistent state.

05CI + docs

Docker, GitLab CI and SwaggerHub delivery.

Constraints that shaped the solution

  • Different external channel APIs.
  • Asynchronous message delivery.
  • Consistent ticket state across systems.
  • Team coordination in a time-bounded university project.

04 · Decision ledger

The trade-offs behind the implementation.

DecisionReasonTrade-offOutcome
Normalize messages at the boundary

VK and Telegram exposed different payloads and delivery behavior.

Adapter maintenance for each channel.

Core ticket workflows remained channel-independent.

Document contracts alongside implementation

Five engineers needed a shared integration language.

Documentation required continuous maintenance.

Service boundaries were easier to coordinate and review.

05 · Change

Before and after.

BeforeDisconnected support channels

AfterNormalized multi-channel intake

BeforeChannel-specific ticket logic

AfterShared workflow service

BeforeImplicit integration behavior

AfterSwaggerHub API documentation

06 · Outcomes

Technical change translated into team value.

Technical
  • Integrated VK, Telegram and OTRS through asynchronous Python services.
  • Implemented PostgreSQL-backed workflow behavior.
  • Set up containerized delivery and CI.
Organizational
  • Coordinated a five-person backend team.
  • Created clearer ownership through service and API boundaries.
  • Improved shared understanding with maintained technical documentation.

07 · Evidence boundary

Precise claims build more trust than inflated ones.

  1. The case reports team size and named integrations from the project record.
  2. No unsupported user-volume or response-time claims are included.
  3. The architecture diagram is a simplified responsibility map.

08 · Reflection

What the project changed in my engineering judgment.

What worked

Normalizing channel data early prevented communication-specific behavior from leaking into the ticket workflow.

What I would improve next

I would add idempotency keys and event tracing as first-class integration requirements.

What this demonstrates

Early backend leadership, integration architecture and asynchronous Python delivery.

Next case · 11Python automation across five external platforms