My 1Finance Modules

"1Finance has two API ecosystems. The older one is a WordPress platform with ~141 custom REST routes across a custom theme and roughly 30 plugins — credit-card, mutual-fund, debt, events, masterclass, sitemap, product-scoring all live there. We're progressively migrating capabilities to a newer Go/Fiber platform, which is where most of my work happens.

On the Go side, we have around 30 feature namespaces. I'm a team contributor — I own several modules end-to-end and contribute to others. The platform patterns we use across modules are consistent: Fiber router groups for namespacing, a DB-backed JWT middleware (CheckUserDataBase) that takes a permission string for endpoint-level RBAC, a separate static-token middleware (StaticTokenAuth) for internal / server-to-server endpoints, and per-resource body validator middleware."

1. Magazine

Routes: /magazine/v1/* • RBAC: ExportMagazineRegistrations / GetAllMagazineRegistrations / Static tokens

Summary: Public registration endpoint plus admin tooling for the 1Finance print magazine.

What you own:

• Public POST register (static-token-gated so only our website can call it)
• Admin GET list of registrations (JWT + permission gated)
• Admin CSV export (JWT + permission gated)
• Admin GET filtered registrations (yesterday's data — for cron jobs, static-token gated)
• One-time encryption backfill endpoint to re-encrypt legacy plaintext rows (JWT + permission gated)

Likely interview questions on this module:

• Why three different auth modes (JWT, JWT+permission, static-token) on one module?
• How do you ensure the encryption backfill is idempotent and safe to re-run?
• How would you scale CSV export if registrations grew to millions?
• What happens if the backfill runs partially and fails halfway?

What to say if asked "walk me through this":

"The Magazine module has three trust tiers. The public registration endpoint accepts a static token because only our website should call it — JWT is overkill and would force users to log in. Admin endpoints use our DB-backed JWT with an explicit permission string per endpoint, so I can give the editorial team a role that can list and export but not encrypt. The encryption backfill is gated by a different static token kept only in our deployment secret store — it mutates every row, so even an admin with the right JWT permission could ruin data with one misclick. The backfill itself is idempotent: it checks each row's ciphertext header before re-encrypting."

2. In-the-News V3

Routes: /in-the-news/v3/* + /news-authors + /news-publications • RBAC: ManageInTheNews

Summary: Admin pipeline for press mentions of 1Finance, plus related Authors and Publications.

What you own:

• Public read endpoints: GET /v3/landing, GET /v3/archive
• Admin nested under /v3/admin — list, get, create, patch, delete (all JWT-gated)
• Admin actions: toggle type, toggle publish, refresh snapshot (open-graph metadata from source URL)
• Body validator middleware (ValidateInNewsBody) for create/update
• Related resources: news-authors and news-publications CRUD (same RBAC permission)
• Kept V1 routes alive for a separate internal consumer until they migrated

Likely interview questions on this module:

• Why did you create V3 instead of evolving V1?
• Why is publish a separate PATCH endpoint instead of being part of the update body?
• What does 'refresh-snapshot' do — and how do you avoid blocking the admin request on an external fetch?
• How do you maintain V1 and V3 in parallel without divergence?

What to say if asked "walk me through this":

"V3 was a clean redesign because V1 had grown organically with flat endpoints and no body validation. I introduced separate public read endpoints (landing and archive) and a nested admin group behind one RBAC permission. Publish is a separate action because in practice editorial wants to update content multiple times before going live — making publish explicit avoids accidental releases. Snapshot refresh fetches OG metadata from the source URL; I keep it as an explicit admin action rather than auto-refreshing because the source can be flaky and I do not want to block admin save flows. V1 stayed live with its old consumers; we sunset it next quarter."

3. HR Conclave

Routes: /hr-conclave/* (V1 + V2 speaker cards) • RBAC: GetAllHrRegistrations / ManageHrConclaveSpeakers / ManageHrConclaveLogos / ManageHrConclaveNominees

Summary: Event microsite — registrations, speakers (V1 nested schema + V2 flat rich-text), logos, nominees.

What you own:

• Public POST register
• Public GETs for speakers (V1 + V2), logos, nominees
• Mail send endpoint
• Admin CRUD for V1 speakers (nested schema)
• Admin CRUD for V2 speaker cards (flat schema with rich-text short_about + content) — reuses V1 RBAC permission
• Admin CRUD for logos and nominees with body validators
• Internal/dev-only encryption backfill (static-token gated) for legacy plaintext rows

Likely interview questions on this module:

• Why introduce V2 speakers instead of modifying V1?
• Why reuse the V1 RBAC permission for V2 endpoints?
• How do you handle rich-text content storage and sanitization?
• How is the encryption backfill different from Magazine's? Why?

What to say if asked "walk me through this":

"HR Conclave V2 speakers came up because marketing wanted a flat schema with rich-text content for richer landing pages. V1 was already consumed by the live event site, so I added V2 routes side-by-side. Crucially I reused the same ManageHrConclaveSpeakers RBAC permission so existing admin roles worked immediately — that turned a schema migration into a non-event for the admin team. Body validation for V2 sanitizes the rich-text against an allowlist of tags. The encryption backfill pattern is the same template I used for Magazine — static-token-gated, idempotent."

4. Master Class

Routes: /master-class/v1/* • RBAC: MasterClassAdminEvents / MasterClassAdmin

Summary: Educational events platform — admin event CRUD, guest CRUD, public OTP-based enrollment, audio/video delivery.

What you own:

• Admin event CRUD + soft delete (events permission)
• Admin guest CRUD + soft delete (guests permission — separate from events)
• Admin enrollment lists (both filtered and full)
• Public POST get-otp + POST enrollment + POST enrollment-validation
• Public GET event audio by slug + event video by slug (gated content delivery)
• Public POST masterclass questions + POST add-feedback
• Public POST get-all-events with filtering

Likely interview questions on this module:

• Why are there two separate admin permissions (events vs guests)?
• How does the OTP flow work — where is it stored, how do you prevent brute-force?
• Why is content delivery (audio/video) by slug and not by ID?
• How would you protect audio/video URLs from being shared publicly?

What to say if asked "walk me through this":

"Two admin permissions because event ops and guest data have different sensitivity — guest contact info is PII, event content is not, so I want to give content editors event-write without exposing the guest list. The OTP flow stores hashed OTP + attempt count + expiry; we cap attempts at 5 and rotate the OTP after the cap. Audio/video delivery is slug-based because that is what marketing wants in URLs; the actual media URL we return is a short-TTL signed S3 URL so it cannot be casually shared. The enrollment-validation endpoint is what protects the actual content delivery — we check the user has a valid enrollment before returning the signed URL."

5. QFA (Qualified Financial Advisor)

Routes: /qfa/v1/* • RBAC: ManageQfa / DeleteQfa

Summary: QFA content management — articles, full data lookups, key questions, and search.

What you own:

• Public POST get-all-qfa (filtered), POST get-all-data (full payload)
• Public GET by ID, GET search
• Admin CRUD with separate Manage and Delete permissions
• Admin CRUD for key questions (linked to QFA records)

Likely interview questions on this module:

• Why is search a GET (with query params) but get-all is a POST?
• Why split Manage and Delete into different RBAC permissions?
• How does the search work — full-text, prefix, fuzzy?

What to say if asked "walk me through this":

"Get-all is a POST because the filter payload can get large enough to bump up against URL length limits and we wanted clean cacheability boundaries. Search stays GET because it is short, single-string, and CDN-cacheable. Manage and Delete are separate because delete is irreversible in our setup — I want a senior reviewer role that can edit but not destroy. Search currently runs as a Postgres ILIKE on title + body with a GIN trigram index; the next iteration moves it to a managed full-text or a dedicated search service if precision becomes an issue."

6. App Reviews + MoneySigns

Routes: /app-reviews/v1 + /admin/app-reviews/v1/* • RBAC: ManageReviews / DeleteReviews / ManageMoneySigns

Summary: App review content and the 'money signs' personality categorization that appears alongside reviews.

What you own:

• Public GET app reviews
• Admin Review CRUD (full CRUD with separate Manage and Delete RBAC)
• Admin MoneySigns CRUD (separate permission)

Likely interview questions on this module:

• Why is the bulk reviews endpoint a POST (get-reviews) instead of a GET?
• How are reviews + MoneySigns related in your data model?
• How would you support different MoneySigns per market / locale?

7. App FAQ

Routes: /app-faq + /admin/app-faq • RBAC: CreateFaq / UpdateFaq / DeleteFaq / CreateFaqCategory / UpdateFaqCategory / DeleteFaqCategory

Summary: App-facing FAQ with categories — public access via static token, admin CRUD with granular RBAC.

What you own:

• Public GET (static-token gated) — category-wise listing + by-slug lookup
• An obscured public GET /qYuvFcIbUGUczDyg endpoint (obscure-by-path pattern for legacy app versions)
• Admin item CRUD with separate Create/Update/Delete permissions
• Admin category CRUD with separate Create/Update/Delete permissions

Likely interview questions on this module:

• Why split FAQ Create / Update / Delete into three separate RBAC permissions?
• What is the obscured-path endpoint and why does it exist?
• How do you handle FAQ versioning when the underlying product changes?

What to say if asked "walk me through this":

"Granular RBAC because the FAQ team is bigger than the dev team — junior content editors get Create+Update, only the team lead gets Delete. The obscure-path endpoint is a legacy access pattern for an older app version that did not support headers; we accept that it is security-through-obscurity and have it on a roadmap to retire when that app version drops below threshold. FAQ versioning is currently editorial responsibility — they soft-edit and we let the latest content win."

8. Header Search

Routes: /api/search + /api/search/click + /api/search/abandon + /api/search/add-blog-popular • RBAC: Static-token (GA4_STATIC_TOKEN) for popular blog ingestion

Summary: Type-ahead search for the website header, with click and abandon analytics.

What you own:

• Public GET /search (type-ahead)
• Public POST /search/click (analytics)
• Public POST /search/abandon (analytics)
• Static-token-gated POST /search/add-blog-popular (called by analytics pipeline to bump popular blogs)

Likely interview questions on this module:

• How do you make type-ahead search fast?
• What do you do with click vs abandon data?
• How is 'popular blogs' computed and what feeds the add-blog-popular endpoint?
• How do you handle multiple content types (blog, masterclass, QFA, products) in one search?

What to say if asked "walk me through this":

"Type-ahead is hit-or-miss without ranking, so we score results across content types — blog, masterclass, QFA, and products. Click and abandon events are forwarded to GA4 and also written to a sorted set in Redis so we can boost recently-clicked items. The add-blog-popular endpoint is hit by an external GA4 pipeline on a schedule with a static token — it feeds an editorial signal into the search ranker."

9. Ticker (landing page settings)

Routes: /landing-page/settings + /v1/ticker/* • RBAC: GetAllTickerInfo / CreateTickerInfo / UpdateTickerInfo / DeleteTickerInfo

Summary: The ticker that appears at the top of the landing page — admin tooling + a public settings endpoint.

What you own:

• Public GET landing-page/settings (returns currently published ticker)
• Admin CRUD with status toggle (separate endpoint for status — same Update permission)

Likely interview questions on this module:

• Why is the public endpoint named landing-page/settings instead of ticker/published?
• How do you ensure the landing page caches the ticker safely?
• What happens if two admins toggle status concurrently?

10. Sitemap Generators

Routes: /sitemap/v1/*

Summary: XML and JSON sitemaps for each financial product category, plus a combined site-wide XML.

What you own:

• Mutual Funds sitemap (JSON + XML)
• Health Insurance sitemap (JSON + XML)
• Term Insurance sitemap (JSON + XML)
• Credit Card sitemap (JSON + XML)
• Home Loan sitemap (XML)
• Static pages sitemap (XML)
• Combined all-sitemap XML
• NPS sitemap XML

Likely interview questions on this module:

• Why expose JSON and XML for the same data?
• How do you avoid regenerating the full sitemap on every request?
• How do you handle URL counts above the 50K-per-file XML sitemap limit?

What to say if asked "walk me through this":

"JSON variants exist for our own admin UI to preview what would be included. XML is served to search engines via the sitemap index. We cache the XML output in Redis with a 6-hour TTL and a background job refreshes earlier than expiry to avoid stampedes. If any single category grows above ~40K URLs we will split it into paginated sitemap files referenced from the index."

11. CSV Bulk Imports

Routes: /csv-upload/v1/* + /credit-card/v1/import-* + /health-insurance/v1/import-* + /nps/v1/import • RBAC: ImportEquity / manageHealthInsurance / manageCC

Summary: Admin endpoints for importing financial product catalogs from CSV.

What you own:

• MF Overlap import
• Health Insurance import + Insurance Companies import
• Credit Card import + Credit Card Weightages import
• NPS import

Likely interview questions on this module:

• How do you process a large CSV upload — sync or async?
• How do you handle partial failures inside a CSV?
• How do you prevent duplicate or stale data after multiple imports?

What to say if asked "walk me through this":

"Imports are synchronous for our current row counts but I built them so the controller is a thin wrapper over a service that takes an io.Reader — that means moving to S3-upload + background worker later is mechanical. Partial failures: we stream-parse, validate row by row, and write to a staging table inside a transaction; on success we swap the staging table's rows into production with an UPSERT. That gives us atomic semantics from the consumer's perspective."

12. Activity Dashboard / Media Converter / Bulk Mailer / Feedback / Options

Routes: various

Summary: Smaller utility endpoints scattered through the platform.

What you own:

• /activity/login + /activity/logo — internal dashboard analytics for login + logo events
• /media/v1/media-converter — JWT-gated media uploader that converts to WebP
• /mailer/v1/send-bulk-mail — admin bulk mailer
• /feedback/v1 — public feedback submission + admin listing
• /options/v1 — generic key-value options store
• /landing/v1/landing-sequence/:category — landing page module sequencing

India HR Conclave — HR Community Platform (hrbackend/v2)

Gateway :8000 → 7 built services + 2 stubs • /api/v1/<resource>/*

What the product is: a gated professional community for HR practitioners — approval-based membership rather than open signup, member profiles, blogs with a public feed, a Q&A surface where members post queries and answer each other, workshop requests, and peer referrals.

The feature that makes it technically interesting: a points and rewards layer used to drive engagement. Members earn points for completing their profile, following the LinkedIn page, referring peers, publishing a blog and other admin-defined tasks, then redeem them for vouchers at 1 point = ₹1. A growth mechanic whose currency is real money — so it is built with financial-grade discipline rather than gamification-grade.

What you can speak to (as a contributor):

• The points ledger — append-only with a DB trigger, one write path, deterministic idempotency keys, relative balance updates under a row lock
• Transactional outbox + Kafka — the event row written in the same transaction as the state change; at-least-once delivery paired with idempotent effects
• Redemption saga — reserve-then-confirm, compensation on definitive failure, and a distinct state for an ambiguous provider response
• The gated membership model — approval workflow, onboarding gate, suspend-never-delete
• The referral loop — the referrer earns when the referee is approved, which is the anti-abuse design
• Deterministic PII encryption so encrypted email and phone still back unique indexes and equality lookups

Likely questions on this system:

• Isn't a ledger over-engineered for a community site?
• Why check the idempotency key before the sufficiency check?
• How do you get exactly-once processing? (You do not — at-least-once plus idempotent effects.)
• A provider call times out: refund or confirm?
• Why does the referrer earn on approval rather than on signup?
• What does deterministic encryption leak, and why accept it?
• And the one that decides the rest: what did you personally do on it?

What to say if asked "walk me through this":

"It's a gated community platform for HR professionals — members are reviewed and approved rather than just signing up, and they profile, blog, ask and answer each other's questions, and refer peers in. To drive engagement there's a points feature where a point is a rupee, redeemable for vouchers. I contributed to that system rather than designing it, but it's where most of my distributed-systems exposure comes from — because a growth feature that pays real money is a fraud surface, so it's built with financial-grade discipline: balances are a cache over an append-only ledger, every movement carries a deterministic idempotency key, and credits are applied by a worker consuming an event rather than on a request path. I'd be happy to go into the specific pieces I worked on."

Full deep dive with architecture, invariants, failure modes and traps: HR Community Platform →

When asked "what do you work on?", do not just rattle off names. Pick one or two modules where you can go deepest, and lead with them. The strongest combinations are:

• Magazine — best for showing auth-tier design + idempotent migrations
• In-the-News — best for showing API-versioning and clean redesign
• HR Conclave V2 speakers — best for showing backward-compatible schema evolution
• Master Class — best for showing OTP/auth + signed-URL content delivery

For distributed-systems depth, reach for the HR community platform instead — but lead with what you personally did there before discussing the ledger or the saga.

For depth questions, lean on the actual patterns you use: Fiber router groups, CheckUserDataBase permission-keyed RBAC, StaticTokenAuth for internal endpoints, per-resource body validators, and the V1↔V3 coexistence pattern during migrations.