Secure & Scalable: A simple platform architecture you can deploy in a weekend (Part 1)

What you can expect to learn: a useful platform architecture for standing up a net-new system (or transforming your current one), along with some background and context of when this would be a good idea to implement.

Imagine you’re a startup or small business unit of a larger enterprise. You are setting out to build a new platform for your customers. The requirements are pretty much unknown other than the usual suspects: the data needs to be secure and the system needs to be fast. Software engineers love ambiguity, so be ready to get exactly what you want with no questions asked. (If you couldn’t tell, the last sentence was sarcasm — and ironically grounded in a lot of reality.)

Anyway, here is the shopping list of apps and services that you’ll need, split into some loosely defined domains of knowledge:

P.S the architecture is cloud provider agnostic, meaning you should be able to apply the pattern with AWS, GCP, or Azure.

Front-end app(s)

The options are building a web app that is meant for desktop and mobile, building a native app, or a combination of the two. If your team is small, it might be difficult to do both, so you’ll need to figure out what is best in the short term. Luckily, the architecture doesn’t lock you into one or the other.

My suggested technology for a web app is Next.js. This framework couples React and Node in an easy to understand project structure. There are guides for containerization, and additional telemetry/app metrics if you deploy to Vercel. Based on the architecture, you can deploy this app to Vercel or another cloud provider — we will assume GCP as our cloud provider in the example.

The suggestion for native app development is Flutter. This is a cross-platform framework that will produce an app for Android and iOS based on a single codebase. I’ve been working with this over the past 2 years and it has gotten leaps and bounds better. Building the UI is declarative, so it reminded me a lot of React and that made the learning curve less steep. I would not suggest Flutter if you need to do compute intensive things like 3D graphics because you may need to optimize low-level code and that would be a lot of work.

Back-end app

When I was first trying to figure out how to stand up all of these things from scratch, I failed pretty hard in the design of my APIs. Which is ironic because my background is API development. The main mistake I made was over-engineering the solution based on the context: I was the only senior technical person at these new startups. I had a bunch of concerns like scaling and keeping the code as clean as possible so I wasn’t constantly confused and onboarding was a bit easier. The initial approach was this beautiful monster of an API network, with business logic split into different micro-services. This is a very enterprise-centric approach, and only works when you have a good budget and a larger team. We quickly made the effort to consolidate services because we were running into issues with cost and cleanliness.

All that to say, my suggestion is to run a single containerized service, referred to as the ‘Core API’. The purpose of this app is to contain the necessary business logic, interface with your datastore, and integrate with other 3rd party services. My concerns about scalability are addressed when we deploy the container using a container orchestration service and code cleanliness was addressed by switching from Flask/FastAPI to Ktor.

Serverless Functions

Cloud Functions (Lambdas in AWS) are a really great way to have small pieces of code run in a cost-effective way. With this architecture, I recommend using them to supplement API functionality where data permissions are not needed. The example I like is to have a Function for Slack notifications. It can be securely invoked from the front-end and the back-end, and is sort of adjacent to the rest of the platform.

To be continued…

Look for Part 2 where we discuss suggestions around Infrastructure, Datastore, App Services, provide a diagram and give our conclusion.