We're building a social networking platform from the ground up — feed, posts, reels, stories, comments, reactions, chats, calls, livestreams, marketplace. We're looking for backend engineers to take ownership of significant parts of the system.
What you'll work on
Concrete things on the next 12 months of the roadmap:
- Feed generation, distribution, and the recommendation engine across posts, reels, stories, comments, and reactions: fan-out-on-write vs fan-out-on-read tradeoffs per content type, candidate generation, ranking pipeline (recency, affinity, engagement signals, content-type mixing), cold start, low-latency serving under heavy read load. - A polymorphic engagement service (likes, comments, mentions, hashtags) across six content types, feeding engagement signals into the ranking pipeline. - A real-time chat layer: WebSocket gateway with multi-device fan-out, Redis pub/sub event routing, presence and typing indicators. - Audio/video calls: WebRTC signaling reusing our WS infrastructure, TURN/STUN, peer-to-peer media transport with SFU upgrade path. - A marketplace service with Stripe Connect (escrow, separate charges, payout scheduling, KYC). - Livestreams: RTMP ingest, HLS delivery, burst push notifications to follower bases of 100K+, integration with our chat infrastructure. - CDC pipelines feeding OpenSearch for full-text and geo-search.
The stack
- Language: Go. - Storage: PostgreSQL (relational), Cassandra/Amazon Keyspaces (high-write event logs), Redis (cache, pub/sub, ephemeral state), ClickHouse (analytics), OpenSearch (search). - Platform: AWS EKS, all services as containers, API gateway. - Observability: OpenTelemetry → Grafana OSS stack (Loki, Tempo, Mimir) for logs, traces, metrics, and alerting. - Async: WebSocket, Redis pub/sub, FCM/APNS for push. - Workflow: Product writes BRDs → we design the OpenAPI/AsyncAPI spec → backend ships a mock service → all teams develop in parallel → swap to real → QA → release. AI-assisted coding is part of how we work, not a side experiment.
What we're looking for
- Strong system design instincts. You can read a BRD, sketch the service boundaries, choose the right storage for each access pattern, and explain the tradeoffs. We care about this more than any specific framework. - No tool tribalism. You pick the simplest thing that solves the problem. You don't reach for Kafka when Redis pub/sub does the job, and you don't reach for Postgres when the workload is append-only events. - Production Go experience building backend services that are actually live somewhere, and comfort with concurrency primitives. - Hands-on with at least most of: PostgreSQL, Redis, a wide-column store (Cassandra/Scylla/DynamoDB), an API gateway, containerized deployments on Kubernetes, OpenTelemetry-style observability. - Independent operator. You don't wait to be told what to do next. You read the spec, identify the unknowns, ask the right questions early, and ship.
Bonus
- Feed, timeline, or recommendation systems experience — fan-out architectures, candidate generation, ranking pipelines, ML-served scores in a serving path. - Real-time systems experience (WebSocket gateways, presence, pub/sub fan-out). - WebRTC or media-server work. - Marketplace or payments work (Stripe Connect especially). - Search infrastructure (OpenSearch / Elasticsearch, CDC pipelines). - Terraform and infra-as-code comfort.
How we work
Small team, flat structure. Two-week sprints. Backend engineers own their services end-to-end: design, build, observe in production, fix. Engineers are expected to read specs, identify unknowns, ask questions early, and ship without being assigned next steps.
