feed-service — business features

1. What it is

feed-service is the place where a company talks to its own staff: an admin posts an announcement, employees see it in the mobile app, react to it, and the app records who has already seen what. It was also designed to celebrate achievements automatically — certificates, recognition, rewards, leaderboard wins — but that half of the product does not run today (see §8).

2. Feature map

flowchart LR
  ADMIN["Admin (admin web)"] --> ANN["Publish announcement"]
  ADMIN --> MOD["Moderate posts"]
  ADMIN --> CFG["Auto-post settings"]
  EMP["Employee (mobile app)"] --> READ["Read the feed"]
  EMP --> REACT["React to a post"]
  EMP --> SEEN["Mark posts seen"]
  EMP --> LIVE["Live updates (SSE)"]
  UA["users-auth-service"] --> GDPR["GDPR export"]
  ANN --> R1["POST /v1/admin/posts"]
  ANN --> N1["publish training.notifications...feed.*"]
  MOD --> R2["PATCH/DELETE /v1/admin/posts/*"]
  CFG --> R3["/v1/admin/announcement-feed/config"]
  READ --> R4["GET /v1/mobile/feed*"]
  REACT --> R5["/v1/mobile/posts/{id}/reactions/*"]
  SEEN --> R6["/v1/mobile/posts/*/viewed"]
  LIVE --> R7["GET /v1/feed/sse"]
  GDPR --> R8["GET /v1/internal/export/{user_id}"]

3. Features

Admin

Employee (mobile)

Internal (other services)

Background

4. API reference

Every route the scanner found. "Callers" lists only non-test callers: feed-service's own tests/ smoke scripts hit most of these paths and do not count as evidence.

5. Async contracts

Consumes

Sixteen registrations: the same eight subjects are registered twice, once by the SSE router and once by the auto-post pipeline. Neither registration site executes in the deployed image, so every row below is dead — but for two different reasons, and each reason is independent of whether the subject has a producer.

Publishes

Background jobs

6. Data it owns

Postgres logical DB feed_db. feed-service is the only writer; no other service reads or writes these tables (ARCHITECTURE.md §3.4).

No cross-service writes in either direction. The only shared infrastructure is the Redis instance (users-auth-redis), where feed-service uses its own index 5.

7. Dependencies

flowchart LR
  MOB["Mobile app"] --> FS["feed-service"]
  ADM["Admin web"] --> FS
  UA["users-auth-service (GDPR CronJob)"] --> FS
  K8S["kubelet probes"] --> FS
  FS --> UA2["users-auth-service (profile batch)"]
  FS --> PG[("feed_db")]
  FS --> RD[("Redis index 5")]
  FS --> NW["notification-worker (via NATS)"]
  ML["micro-learning-service-v2"] -.->|"events nobody consumes"| FS

Dotted edge: micro-learning publishes the training subjects feed-service registers for, but the registrations never execute, so no message is ever delivered.

8. Dead-code verdicts

Every entry point with no in-repo caller. Deleting is a separate decision — see the hub roll-up.

9. Sources

• feed-service/docs/sdd.md — the original Social & Announcements design: goals, intended event sources and published events.
• feed-service/docs/flutter_user_state_integration.md — the mobile client contract; the only in-repo document that names concrete mobile paths.
• feed-service/docs/testing_checklist.md, feed-service/docs/TEST_RESULTS.md — behavioural expectations per endpoint and event.
• feed-service/USER_STATE_IMPLEMENTATION.md, feed-service/VIEW_TRACKING_IMPLEMENTATION.md — the user-state and view-tracking design notes.
• bug-hunt-reports/feed-service.md — 14 findings; #2, #5, #6, #12, #13 are load-bearing for this page.
• ARCHITECTURE.md §2 (inventory), §3.2 (HTTP edges), §3.3 (streams), §3.4 (databases), §3.5 (Redis map), §4.1(5) (the feed defect this page narrows).
• Code read directly: app/main.py, app/core/health.py, app/routes/*.py, app/services/event_processor.py, app/events/nats_publisher.py, app/clients/users_auth_client.py, migrations/versions/, k8s/.
• Cross-service verification: micro-learning-service-v2/app/events/events.py, users-auth-service/app/routes/users.py, users-auth-service/app/services/gdpr_export.py, notification-worker/app/services/notification_service.py.