cobrother-official/cobrother_backend

1. This repository is a production FastAPI backend for a multi-domain marketplace platform called CoBrother. It serves authentication, domain registration/transfer, venture listings and deals, technology/cocreation sales, creator/community features, auctions, payments, analytics, admin operations, and real-time notifications.

2. The top-level runtime entrypoint is app/main.py, which assembles the FastAPI app, middleware, lifespan tasks, and route registration. Cross-cutting concerns live in app/core/ and include configuration, database session wiring, auth dependencies, rate limiting, security, logging, request middleware, and bot protection.

3. The code follows a layered backend architecture: HTTP controllers in app/controller/ receive requests; services in app/service/ hold business rules and orchestration; repositories in app/repository/ perform database access; SQLAlchemy entities in app/entity/ define persistence models; Pydantic models in app/model/ define request/response contracts. This separation is the main architectural boundary.

4. The system uses two database access paths, which is an important architectural split. get_db is the synchronous path used for auth, admin, analytics, meetings, and some ancillary workflows. get_async_db is the asynchronous path used heavily for auctions, ventures, domains, payments, and cocreation. Diagrammatically, this is a major boundary between request handling and persistence.

5. The application is organized into product subsystems rather than a generic CRUD structure. The major domains are auth/user management, domain marketplace and registration, venture/coventure management, technology/cocreation listings and software auctions, community/creator profiles and auctions, payments and payouts, analytics, notifications, and admin moderation. Each of these has its own controller/service/repository/entity stack.

6. Domain operations form one of the most complex flows. Controllers under app/controller/domain/ call services such as registration, transfer, verification, escrow, dispute handling, and notifications. Those services integrate with registrar providers, WHOIS/RDAP lookups, GST/verification helpers, and payment/escrow logic. This subsystem also has marketplace-specific entities for listings, transactions, transfers, and disputes.

7. Venture and CoVenture are modeled as a separate business line with its own data and workflows. Controllers and services in app/controller/venture/ and app/service/venture/ handle venture listings, company profiles, financial profiles, pitches, deals, acquisition applications, and verification/GSTIN-related checks. The model is richer than simple listing CRUD and includes governance and deal lifecycle concepts.

8. Technology/cocreation covers software listings, auctions, purchases, completion, and verification. The controllers split between technology and cocreation, and the README notes some endpoints are dual-mounted for compatibility. Services here coordinate listing gates, auction participation, purchase completion, and payment flows, with dedicated entities for software, auctions, bids, participation, and payment status.

9. Community and creator features are another distinct subsystem. This includes communities, posts, comments, likes, follows, creator expected rate, meeting scheduling, and creator auctions. The meeting flow is especially important: bidders request meetings, the profile owner confirms through Google OAuth, and the system creates Google Calendar/Meet events and sends SMTP emails.

10. Payments and money movement are distributed across several verticals rather than centralized in one module. Razorpay is integrated for payments, while payout tracking and seller payout profiles live in dedicated payout services and entities. Domain registration, auctions, and software purchases each have payment-related states and transaction records, so payment behavior is embedded within the business flows instead of isolated.

11. Background and real-time behavior are first-class. app/background_jobs.py and lifecycle startup tasks handle auction expiry timers and scheduled cleanup/retry jobs. app/websocket/ provides SockJS/STOMP-compatible channels for auction updates and notifications, with a connection manager and event routing layer. This means some state transitions are pushed asynchronously to clients rather than only returned via HTTP.

12. External integrations are concentrated under app/integrations/ and materially shape the architecture. The backend talks to Google OAuth, Calendar, and Meet; SMTP mail; Razorpay; Supabase/S3-style storage; ResellerClub and OpenProvider domain registrars; Redis; GST validation; and WHOIS/RDAP services. These integrations are invoked by services, not controllers, keeping provider-specific logic out of the API layer.

13. Analytics and observability are implemented as product features, not just ops tooling. There are view-tracking entities and repositories for profile, venture, software, and domain listing views, plus analytics services and controller endpoints. This subsystem feeds reporting and ranking-style behavior across multiple product areas.

14. Alembic migrations are a major operational boundary. The repository contains a large migration history with many merge revisions, reflecting concurrent evolution of multiple domains. The README emphasizes maintaining a single Alembic head and blocking deploys if the schema graph diverges, so schema management is part of the production architecture.

15. Deployment and environment assumptions matter to the architecture. The app expects PostgreSQL, uses environment variables for secrets and external services, ships Docker and Nginx config examples, and includes CI/CD workflows for Alembic checks and deployment. Health and readiness endpoints support operational monitoring, while the tests are broad and domain-specific, reinforcing the service-oriented modular structure.