[Backend Engineering · Databases · Software Architecture]
Backend Architecture & Data Persistence
The server architecture that holds the platform together: accounts, signals, settings, states, background jobs, access control, reports and monitoring — evolving without rewrites.
01Project overview
Every other case on this site depends on this layer. It stores users, signals, settings and states, runs background processes, talks to external APIs and delivers information to Telegram and web interfaces.
The emphasis is on controlled evolution: adding features and fixing issues in a system that already has many moving parts, with verification before every change reaches production.
02Engineering challenge
When many subsystems share a database and run concurrently, the hard problems are consistency, failure handling and change management — not any single feature.
- A
Keep state consistent between user actions and background processes.
- B
Handle incorrect or partial data from external services.
- C
Schedule background operations without overlapping or losing work.
- D
Make every important event traceable through logs.
03Solution architecture
Hover or tap each stage.
External APIs
Exchanges, Telegram, AI providers and other services.
Monitoring and event logs observe every stage.
04Main components
- 01
Data model
SQL tables and relationships for accounts, signals, settings, states and event history.
- 02
Service layer
Async Python services that encapsulate business logic and external integrations.
- 03
Workers
Background processes for scheduled and long-running tasks.
- 04
Integrity checks
Validation of inputs and invariants before writes.
- 05
Event logging
Structured logs that tie user actions and background work together.
- 06
Delivery
Endpoints and messages that bring results to Telegram and web interfaces.
05Technology stack
Core
- Python
- async / await
- aiohttp
Data
- SQL
- SQLite
- Data modeling
Operations
- Linux VPS
- Background processes
- Structured logging
06Interactive demonstration
Request path through the backend
IllustrativeIllustrative demo. Send a request through the layers and inject a failure to see how errors are handled and logged.
$ tail -f app.log
Monitoring
- processed
- 0
- deduplicated
- 0
- retried
- 0
- rejected (invalid)
- 0
- failed → alert
- 0
07Engineering decisions
- 01
Evolve, don’t rewrite
Changes are introduced incrementally behind clear boundaries, verified, then expanded.
- 02
Validate before persisting
Bad data is stopped at the logic layer, so the database stays a reliable source of truth.
- 03
Idempotent background work
Workers can safely re-run after interruptions without duplicating effects.
- 04
Logs as a product feature
Structured, correlated logs make production behaviour explainable.
08Reliability & testing
- Pre-deployment verification of changes against existing behaviour.
- Deduplication of events and idempotent processing.
- Error handling around every external dependency.
- Post-deployment checks of actual behaviour in production.
09Code example
import sqlite3
from datetime import datetime, timezone
def process_event(db: sqlite3.Connection, event_id: str, source: str, kind: str) -> bool:
"""Returns True if processed now, False if it was already handled."""
try:
with db: # one transaction: mark + apply, or neither
db.execute(
"INSERT INTO processed_events (event_id, source, event_type, processed_at) "
"VALUES (?, ?, ?, ?)",
(event_id, source, kind, datetime.now(timezone.utc).isoformat()),
)
apply_side_effects(db, event_id, kind)
return True
except sqlite3.IntegrityError:
return False # duplicate delivery — safe to ignore
def apply_side_effects(db: sqlite3.Connection, event_id: str, kind: str) -> None:
...Illustrative Illustrative Engineering Example — idempotent event processing with SQLite.
Production source is private. Examples here show the engineering approach, not proprietary logic. More in the Engineering Lab.
10Possible extensions
- Migration path to PostgreSQL for higher write concurrency when needed.
- Metrics endpoint for queue depth and job durations.
- Contract tests for the endpoints consumed by interfaces.