Mottika
- Year
- 2026
- Type
- Work project · Tres Astronautas
- Status
- In development
- Stack
- Go
- PostgreSQL
- RabbitMQ
- Redis
- gRPC and OpenAPI
- Next.js and React
- Tailwind CSS
- Turborepo
Summary
Mottika is a multi-tenant transactional switch for a financial-services company. It sits between the systems where card transactions start and the card-management systems that make the financial decision, and it governs how every transaction is checked, routed and recorded.
For each transaction, Mottika confirms that the request is authentic and not a duplicate, works out which client the card belongs to, sends it to the right destination, applies that client's own rules and spending quotas, adapts the message when needed and returns the verdict. After that, it prices the transaction, reconciles it and releases the money. On top of the switch, merchants get a cash desk: sales, shift close, cash count and the handover of collected cash.
Mottika does not issue cards, does not make the authorization decision and does not move money. Each of those jobs belongs to another party, and keeping that line clear shaped most of the design.
The product is made of two consoles on one platform:
- An admin console for the platform team, working across every client.
- A merchant console for each client's team: administrators, cashiers, supervisors and cash receivers, with tablet-first screens for the cash desk.
Mottika is one half of a two-part product. Emisys, documented as its own project, is the visual layer and the channel to the employee funds.
I work on Mottika at Tres Astronautas for a client, on the architecture and the design of the platform. The project is confidential and still in development, so this case study shows flows and diagrams instead of screens.
- 16
- capabilities
- 42
- features
- 38
- user flows designed
Context & role
- Client: A financial-services company. The name is kept private.
- Company: Tres Astronautas
- Product: A transactional switch with an admin console, a merchant console and a cash desk
- My role: Senior Software Engineer, on architecture and design
- What I did: Took part in designing the architecture and writing it down: the system model, the decision records and the flows the build follows
- Status: In development
Problem
Operating cards at scale means connecting many parties that each speak a different dialect. Processors, card-management systems, acquirers and accounting all have their own formats and rules. When each connection is custom code, adding a route or a business rule means writing code and releasing it, and onboarding a new client threatens to mean building yet another system.
The scope of the platform shows where that hurts:
- The platform team needs to change routes, rules and quotas while traffic keeps flowing, without a release for each change.
- Each client needs to manage its own users, keys and rules without waiting for the platform team.
- Cashiers and supervisors need a cash desk where every sale, close and handover can be traced, and where a slow answer never charges a customer twice.
- Merchant administrators need to review reconciliation and approve it before money is released.
The platform team carries most of that weight. It governs every client from one place, and a wrong rule or a broken route affects every transaction behind it, so most of the admin console is designed around changing things safely.
Users & context of use
Five profiles use Mottika, from the team that operates the platform to the people at a merchant's counter. The automated actors, such as the switch itself or a merchant's ERP, are not personas.
Platform administrator
Onboards clients, configures routes, rules, quotas and fees, and watches health, incidents and the audit log across every client.
Admin console
Merchant administrator
Manages the users, keys, projects and rules of one client, sets up points of sale and approves reconciliation.
Merchant console
Cashier
Opens the shift, charges sales, closes the till and hands over the cash. One task per screen, with large targets.
Merchant console, tablet first
Supervisor
Approves adjustments and refunds above the cashier's limit, and the closing of each shift.
Merchant console
Collection receiver
Accepts or rejects the handover of cash, which settles the shift.
Merchant console
The moments that shaped the design
- The cashier at the counter works on a tablet with a customer waiting. A sale with no answer in three seconds had to become a clear "failed" that can be retried, never a charge made twice.
- The supervisor called to approve has two minutes to decide on an adjustment. After that, the answer is no.
- The platform administrator changing a rule does it while real traffic flows. The rule had to be testable before going live, and its activation had to reach every switch without a release.
- The merchant administrator approving a reconciliation needs every difference resolved and explained before money moves.
These moments come from the user flows and the UX blueprint of the project, and they worked as a check for every flow.
Goals, success metrics & constraints
Goals
- Configure routing and business rules instead of coding and releasing them.
- Process each transaction securely, fast and exactly once, even when a third party is slow or down.
- Keep financial integrity from pricing to reconciliation and disbursement.
- Make cash at the counter traceable, from the sale to the handover.
- Onboard a new client without building a new system, with each client isolated from the others.
How success would be measured
No success metrics were agreed with the client yet. These are the ones I would propose, each tied to one of the goals:
| Goal | Metric | What it tells us |
|---|---|---|
| Configured, not coded | Rule and route changes made without a release, and time from draft to active | Whether the platform team really stopped depending on deployments. |
| Fast and exactly once | Latency at the 99th percentile, and duplicate charges detected | Whether the switch keeps its promise under load. |
| Financial integrity | Reconciliation runs approved without open differences | Whether pricing and reconciliation agree. |
| Traceable cash | Shifts closed with a justified difference, and handovers rejected | Where cash still gets lost between the till and the receiver. |
| New clients | Time to onboard a client end to end | Whether a new client is a setting or a project. |
Constraints
- A tight time budget. The switch is designed for 500 transactions per second with a p99 of 500 ms end to end, so everything on the authorization path had to stay in memory but one outbound call.
- Third parties still being defined. Processor test environments, the reconciliation file format and several providers were pending while the design moved forward.
- Choices that changed on the way. Some components, such as the access layer and the identity provider, were changed at the client's request, and the decision records kept those changes cheap to explain.
- Validation still pending. The design deliverables were documented, and the joint validation session with the client's stakeholders was still being scheduled.
Process & prioritization
From problem to scope
The planning started from an impact map that tied business goals to the people and the systems that use the platform. Their needs were consolidated into 16 capabilities and 42 features, each with its acceptance criteria, and then into 7 build chunks.
The design followed the same trail: 20 console modules, 38 user flows and 38 wireframes, all traced back to a capability. Any screen can be followed back to the need it answers.
What the platform covers
| Area | What it enables |
|---|---|
| Clients | Onboard a client and its first administrator in one step, suspend it and reactivate it. |
| Switch | Check, identify, route, apply rules and quotas, adapt the message and record each transaction. |
| Rules and routes | Routing per company, versioned business rules with a sandbox, quotas with alerts and message profiles, all applied without a release. |
| Merchant self-service | Users with roles per module, keys for the merchant's systems, and the merchant's own projects and rules. |
| Pricing and settlement | Fee sheets, reconciliation with traffic-light differences, approval and disbursement. |
| Operations | A live board, incidents, an audit log that cannot be edited and support tickets. |
| Cash desk | Points of sale, catalog, sales, e-invoices, shift close with dual control and cash handover. |
Built in chunks
- Built: client onboarding and suspension, infrastructure registry, projects and routing, merchant users and keys, sign-in with one-time codes, dashboards, and most of the switch path with rules, quotas and message profiles.
- Next: pricing, reconciliation and disbursement, monitoring, incidents, support and the whole cash desk, which are designed and waiting for their chunks.
Design decisions
The decisions that most shaped the platform, made by the team and designed by the product designer of the project, part of the Tres Astronautas team. The project is confidential, so each one is shown as a flow or a diagram instead of a screen.
One path, in a fixed order
Problem. A transaction that can take different paths depending on who configured what is impossible to explain later.
Decision. Every transaction follows the same eight steps in the same order, and the first rejection stops it. Only one step leaves the switch: a single call to the system that makes the financial decision.
Trade-off. Some checks that could run in parallel run one after the other.
In the product. A repeated request gets the stored answer, an adjustment is a new transaction linked to the original, and a switch with no configuration loaded denies everything instead of guessing.
Rules change without a release
Problem. If changing a business rule means writing code and deploying it, the platform team becomes the bottleneck of every client.
Decision. Rules are written as expressions, tested in a sandbox against sample transactions and activated by hand. Each switch reloads the whole configuration as one fixed snapshot.
Trade-off. Configuration needs its own versions, its own tests and a way to know which switch has which version.
In the product. Editing an active rule creates a new version, and nothing is deleted. If a switch does not confirm the reload, the admin sees which one, and a merchant's own rule goes back to draft if no switch confirms it in 30 seconds.
Two signatures for cash
Problem. Cash is where money is easiest to lose and hardest to trace.
Decision. Closing a till needs the cashier and the supervisor, and a handover needs the cashier and the receiver. Every difference needs a reason, and the close report is signed.
Trade-off. More steps at the end of every shift.
In the product. A sale without a verdict in three seconds is marked failed and retried with the same key, so the customer is never charged twice, and an open or failed sale blocks the close.
The client is never a choice
Problem. In a platform shared by many clients, a single wrong filter can show one client's data to another.
Decision. The client always comes from the session or the credential, never from what a person types or selects. In the merchant console, it is always visible.
Trade-off. The platform team needs its own console to work across clients.
In the product. Another client's resource looks as if it does not exist, and suspending a client cuts every user, key and route on its next request, without deleting any history.
Four kinds of message
Problem. "Something went wrong" does not tell a cashier whether to retry, call someone or tell the customer the card was declined.
Decision. Every message is one of four kinds: success, a business rejection, a technical failure or pending. Irreversible actions show their impact before they are confirmed.
Trade-off. Every flow had to name its own failures.
In the product. A declined card and a timeout look different, and each one offers only the actions that make sense.
Design system
The two consoles share one design system, created in Figma by the product designer assigned to the project at Tres Astronautas and documented as a manual of foundations, components and screen templates. The front end reuses the standard already proven in Emisys, so both products feel related without looking the same.
Foundations
- One typeface. Inter for titles, interface, tables and data, with hierarchy from size and weight.
- A teal for action. A five-step teal ramp, with one tone reserved for actions and a soft tint for selection.
- Quiet neutrals. A short gray scale for surfaces, borders and text, so dense tables and rule editors stay readable.
- Status colors with fixed meanings. Success, error and warning each have a background, a fill and a text tone.
- Only tokens. The framework's default palette and radius were removed, so only the system's values can be used, and the dark theme reverses each ramp.
Cash desk on a tablet
The cash-desk views drop the sidebar and use larger controls, one task per screen. The rest of the merchant console and the admin console use a collapsible grouped sidebar and a top bar with the breadcrumb, the theme switch, notifications and the profile.
From design to code
My work on Mottika is on the architecture: designing it with the team and an external architecture partner, writing it down and keeping the build aligned with it. This section explains how the platform is organized, in terms of what each part does.
Architecture
Mottika has two zones. The management zone, behind a single access layer, is where people and their systems configure the platform: clients, projects, rules, quotas, users, keys and points of sale. The transactional zone, behind one gateway per inbound channel, is where the switch processes each transaction with the configuration the control plane publishes.
Pricing, reconciliation and disbursement run off the critical path, driven by events, so a missing fee never blocks a payment. The cash desk sends each sale through the switch like any other channel, and dashboards read from a copy of the data so they never slow down a transaction.
Domain model
The domain is split into eleven contexts, each owned by one part of the system and connected to the others only through identifiers, contracts and events. A client is the unit of isolation. A client has projects, projects group companies, and each card belongs to exactly one company. Configuration, made of routes, rules, quotas and message profiles, is published to the switches as a versioned snapshot that never changes once published.
A few rules hold everywhere: a request is processed once per key, amounts are whole numbers in the smallest unit, a sale only exists inside an open shift, and a transaction without a verdict in time is marked failed and never turns into approved on its own.
Quality attributes
Eight quality attributes were defined, each with measurable acceptance criteria. Latency is protected by keeping everything on the authorization path in memory with a single outbound call. Availability comes from a transactional zone that keeps working when the management zone is down. Resilience means transient errors are retried and definitive ones are not, and auditability rests on two records that cannot be edited, one of who did what and one of what happened to each transaction.
Working with AI agents
The repository carries a harness for people and AI agents working on one codebase: session boards, claims on shared paths and reviewer approval before work is accepted. People make every commit.
Technical decisions
Written decision records explain why each choice was made. The main ones:
| Decision | Why | Trade-off |
|---|---|---|
| Contract-first APIs | No interface or integration touches the database directly. | Contracts must be written before building. |
| A single outbound call per transaction | Latency stays predictable. | Everything else on the path must live in memory. |
| Fail closed | A switch with no configuration denies instead of guessing. | Availability is traded for never approving by mistake. |
| A queue broker instead of a log | The work is tasks with retries, not a history to replay. | The audit lives in its own store. |
| Configuration as a fixed snapshot | A transaction never sees a rule change halfway. | Changes reach the switches in a moment, not instantly. |
| Pricing never blocks authorization | A missing fee must not fail a payment. | Pricing runs after the verdict. |
| Accounting stays outside Mottika | Each product owns one job. | An integration to maintain between the two. |
Results
The foundation of the platform is in place: clients can be onboarded, suspended and governed, each isolated from the others, and most of the switch path is built, with rules, quotas and message profiles applied without a release. The cash desk, pricing and settlement are designed and scheduled for later chunks.
The project is still in development, so there are no production figures yet, and several third parties are still to be confirmed. The written architecture is what lets the build move forward without them: every open dependency has its place in the model and its contract waiting.
Learnings & next steps
Next steps
- Validate the design with the client's stakeholders and adjust the flows with what comes out of it.
- Build pricing, reconciliation and the cash desk on the flows that are already designed.
- Connect the real processors as their test environments become available.
What I learned
- Writing decisions down pays off when they change. Some choices changed at the client's request. Because each one had a written reason and a trade-off, changing it was a conversation about the trade-off, not a debate about memory.
- A switch is mostly about what it refuses to do. The clearest decisions were the boundaries: no money moved, no authorization made, no configuration guessed. Each "no" made the rest of the design simpler.
- Flows show what diagrams hide. An architecture diagram says where the cash desk lives. Only the flow, step by step and with who signs what, makes rules like the two-minute approval window visible to everyone.