Premium Culinary Creator Platform

Το πρόβλημα

Culinary creators publish recipes and service proposals to a paying audience. Readers spend a voting balance to back what they like, creators earn from being backed, and what each side may do depends on the package they hold — so the product is a content platform and a small economy at the same time.

Ship an engineering MVP where the money paths are provably correct: subscriptions, entitlements, wallets and voting all enforced server-side, with the rules in configuration rather than scattered through the code.

Οι δυσκολίες

• ●A vote spends balance, so it is a financial transaction, not a click: insufficient balance has to reject cleanly and two simultaneous votes on the same key must not both succeed.
• ●Entitlements are sold, so what the interface offers and what the server enforces cannot drift apart — every displayed benefit needs a real server-side implementation behind it.
• ●Billing arrives asynchronously by webhook, which has to be signature-checked, deduplicated and able to revoke access when a payment is disputed.
• ●A schema this size only stays trustworthy if the migration chain reproduces the deployed database exactly, rather than being patched by hand along the way.

Η λύση

• ●Votes are an immutable ledger with a rebuildable aggregate: the vote, the voter's debit, the aggregate update and the credit to the recipe owner all commit in one transaction, or none of them do.
• ●Subscription entitlements resolve through a single config-driven service, with a database-level invariant that a profile can hold only one active package at a time and package switches preserve history.
• ●Media lives in a private object store, uploaded and displayed through presigned URLs so files are never public and never pass through the app server.
• ●Domain logic sits in a service layer with thin API route handlers, so the same backend can serve a mobile client later without a rewrite.
• ●One responsive app from phone to desktop rather than separate mobile and desktop builds.